Countable electronic monetary system and method

ABSTRACT

A smart card payment system using stored value in the form of serialized electronic coins and electronic bills, which provides efficient security monitoring without the need for full centralized accounting of each transaction. Central monitoring of the system-level security includes statistical sampling techniques coupled with efficient tracing of the transaction path of an electronic coin back to its source. Only small amounts of data storage and transmission are utilized, eliminating the need for large centralized databases of transaction records. Consumer privacy as well as flexibility in making card-to-card monetary transfers are thereby enhanced, while allowing verification of system-wide security as well as rapid detection and tracing of security breaches. Multiple editions of electronic coins permit transparent and periodic renewal of the system and re-establishment of a security baseline, and also provide for the regular reclamation of stored value lost or abandoned by consumers.

FIELD AND BACKGROUND OF THE INVENTION

The present invention relates to a smart card payment system, and inparticular to such a system with system-level monitoring of the storedvalue.

Smart card technology has enabled two consumer payment applications: thecharge (credit or debit) card with enhanced security (especially inoff-line payment,) and the stored-value card, also called electronicpurse. The two applications are complementary: the charge card is moresuitable for medium-to-higher payments, while the electronic purse'sarena is small payments. The potential synergy between these two paymentapplications is described in a co-pending U.S. patent application Ser.No. 08/533,599 of Sep. 25, 1995, and in its equivalent PCT publicationWO 96/09592, both by the present inventor.

A major concern in any payment system is security, i.e., preventingunauthorized transfer or production of money. In smart card stored-valuepayment, a vast number of patents, publications and implementedsolutions deal with safeguarding payment and other value transfertransactions at the bank-to-consumer, consumer-to-merchant andmerchant-to-bank levels. There are combinations of hardware, softwareand procedures believed to withstand any attack conducted for areasonable time using known means. However, as security is so crucial topayment systems, many bankers insist on monitoring the flow of money atthe system level, to reconfirm the flawless operation of the securitymeans at the transaction levels. This security requirement has beencommonly transformed into the concept of "full accountability", i.e.recording and reporting all single stored-value transactions to acentral computer, for checking and confirming that each addition ofvalue to a first stored-value device has occurred only as the sameamount had been deducted from a second stored-value device. Suchaccountability schemes require an enormous amount of data storage andtransfer and may interfere with the privacy of consumers carryingpersonal payment cards.

OBJECTS AND BRIEF SUMMARY OF THE INVENTION

The main object of the present invention is to monitor centrally thestored value (hereinafter referred-to as "electronic cash") in astored-value system, for system-level reconfirmation oftransaction-level security, without recording and reporting each singletransaction. Another object is to minimize the amount of data stored andtransferred for such monitoring. Still another object is to enableconsumer anonymity and privacy in most small payments. Additionalobjects include measuring the amount of stored value lost or abandonedby consumers; measuring the amount of invalid stored value (iftransaction-level security has malfunctioned or has been broken);providing controlled refresh options for periodical renewal ofelectronic cash and its security parameters; maintaining local audittrails for identifying the sources of fraudulent electronic cash;supporting multiple-issuer environments; and enablingsatisfactorily-monitored card-to-card transfer of electronic cash.

The following terms will be used herein as follows:

1. Electronic money--value which is recorded electronically and isuseful for payment.

2. Account--a storage of electronic money or debt at an institution.Non-limiting examples are bank accounts and credit accounts. Theaccounts of interest to the present invention are consumer account andmerchant account.

3. Financial institution--a business entity establishing and maintainingaccounts. Examples of financial institutions are banks, credit companiesand telephone companies. Actually, the term financial institution willusually relate to the computer system of such institutions used to storeand maintain accounts and execute transactions therewith.

4. Charge--a consumer order to transfer electronic money from hisaccount to another account.

5. Electronic cash--electronic money in a form which can be transferredto and stored in a consumer or merchant electronic storage device.

6. Stored-value device--an electronic storage device for storingelectronic cash.

7. Payment card--a consumer device for payment with electronic money. Apayment card may include a charge card for generating charge orders(e.g., credit card or debit card), and/or an electronic purse, which isa consumer stored-value device.

8. Smart card--a payment card designed to secure the information storedtherein and the transactions made therewith.

9. Point of sale or POS--a merchant's device for receiving payment andoptionally also for determining the purchase contents and calculatingthe payment amount. A POS may be staffed (e.g., a supermarket cashregister) or automatic (e.g., in a vending machine, public telephone orparking meter).

10. Electronic drawer or drawer--a merchant's secured electronic storagedevice, usually forming part of a POS, for storing electronic cash(electronic cash drawer) and/or charge orders (charge drawer).

11. Electronic cash pool--a stored-value device of a financialinstitution, for storing and accounting for electronic cash.

12. Elementary monetary value or EMU--the smallest amount of monetaryvalue that is relevant for payment or change. An example is 1¢ in thePOS, or 5 Agorot in Israel.

13. Serial number--data used for identification of a discrete entity,and suitable for digital representation. Typical examples for serialnumbers are positive integers and ASCII character strings.

The present invention makes electronic cash countable by devising theentity "electronic coin", each electronic coin having a monetary valueand a serial number. When an electronic coin moves, it moves along withits value and serial number. A percentage of random electronic coinsflow through electronic coin pools of financial institutions, whereforbidden repetitions or out-of-range serial numbers are sought. Suchrepetitions or out-of-range instances, if found, are reported to signalthat there is a security leak at the transaction level and to estimatethe size of the damage.

By creating a hierarchy of electronic coin types, each having adenomination which is a multiple of the previous denomination, thepresent invention supports very effective payment while minimizingstorage requirements for electronic coins, especially on the paymentcard. The present invention teaches how to allocate tens or a couplehundred bytes of memory on the card, for storing hundreds of dollars,with 1¢ resolution, in a hundreds million card population, with a uniqueserial number for each electronic coin. This minimal storage requirementalso implies minimal data communication requirement during transactions,which minimizes transaction time and enhances reliability.

The present invention also investigates the money flow in the monetarysystem constructed and operated according to the present invention,showing that most electronic cash actually revolves between points ofsale and payment cards, while the actual monetary transfers are mademainly by charge (credit or debit) transactions and/or by electronicbills, which are higher-denomination electronic coins which are allowedfor manual reloading of payment cards.

Another aspect relates to managing local audit trails, where eachstored-value device records the serial numbers of received electroniccoins along with the identity of the source device. These records arekept for a limited time, and are useful to trace back suspectedelectronic coins to identify, the source devices for furtherinvestigation.

By changing editions periodically, the present invention teaches torefresh security parameters, recall efficiently and automatically theolder edition's electronic coins, count them with accuracy of a singlecent, identify security flaws precisely, and account for electronic cashlost or abandoned by card holders, i.e. electronic cash not claimed bythe expiration date of the old edition.

Other important achievements of the present invention include a veryeffective support for system-level-audited card-to-card electronic cashtransfers, and the provision of ultimate anonymity at most transactions.The invention offers flexibility in supporting different card types topopulations of different needs and preferences, including theco-existence of personal cards having both charge and stored-valuefunctions, and "white", stored-value-only cards. Methods foraccelerating the edition refreshing and enhancing the security samplingrate and reliability are also presented, including forced exchange ofelectronic coins and random or FIFO (first-in-first-out) electronic coinpicking.

The present invention also teaches how to manage a multi-issuerenvironment, where every issuer is assigned a distinctive range ofserial numbers. A semi-countable system is also presented, where higherdenomination electronic coins are counted according to the presentinvention, while lower denominations are inspected statistically. Thereis considerable prior art in the field of transferring monetary valueelectronically, but the present invention differs significantly fromprior art systems with regard to objectives, organization, utilization,and operating environment.

For example, the "Value Transfer System" of U.S. Pat. No. 5,440,634 andU.S. Pat. No. 5,623,547 to Jones et al. disclose a coinless purse systemthat requires a separate loading operation and independent accountreconciliation on individually-stored transactions. This is in contrastto the system of the present invention, which utilizes electronic coinsand does not necessarily require a separate loading operation or accountreconciliation.

It should also be noted in particular that the general concept ofconvenient payment instruments in the form of indivisible digitaltokens, sometimes referred to as "ecoins", is likewise well known in theart. The present invention, however, differs significantly from priorart implementations of "ecoin" payment systems, with regard to itsobjectives, operating environment, and electronic coin transferprotocol.

For example, the prior art "ecoin" payment system of DigiCash BV(Amsterdam, The Netherlands) is intended to facilitate the making ofpayments over a possibly unreliable communication channel (such as adata network) and to reduce the risk of lost value due to storage andtransmission errors. In the DigiCash system, "ecoins" are uniquelyserialized, and any holder of an "ecoin" can make unlimited copies ofthe "ecoin" for legitimate purposes, such as backup against inadvertentloss. In fact, the copies of a DigiCash "ecoin" with a specific serialnumber are indistinguishable from one another, so that it is meaninglessto speak of an "original" DigiCash "ecoin" as distinct from the copiesof that "ecoin". In the DigiCash system, the transfer of an "ecoin" frompayer to payee consists of sending a copy of the "ecoin" from payer topayee. A copy of the "ecoin" remains with the payer, so that the "ecoin"may be sent repeatedly to the payee in the event of communicationserrors or other loss.

The DigiCash system maintains integrity against unauthorized creation ofvalue with a central database containing records of spent "ecoin" serialnumbers, so that any given "ecoin" can be used to transfer value fromany payer to any payee only once. A payee who receives an "ecoin"immediately sends a copy of the "ecoin" to the issuer (usually a bank),who records the "ecoin" serial number in the central database of spent"ecoins" and validates the payment, either by crediting the payee'saccount with the value or by returning a new (unspent) "ecoin" of equalvalue to the payee, which the payee may then spend. But subsequentattempts to transfer value from any payer to any payee using an "ecoin"that is registered in the central database as having already been"spent" will be rejected, and in this way the making of copies of"ecoins" does not impact the monetary value in the DigiCash system.

In contrast, the electronic coin system of the present invention isintended to facilitate the utilization of account-to-account transfers(credit or debit) for making cumulative small payments, and employs ahighly reliable communication channel (a smart card), in which theprobability of a communications or storage failure of the devicesthemselves is negligibly small. In the system according to the presentinvention, electronic coins are uniquely serialized, but the transferprotocol precludes the making of copies. In the system according to thepresent invention, therefore, there exists at most a single electroniccoin corresponding to any given serial number, and the transfer of anelectronic coin from payer to payee consists of sending the electroniccoin to the payee in such a way that no copy of the electronic coinremains with the payer. In the system according to the presentinvention, electronic coins circulate like their physical counterparts,and a particular electronic coin may therefore be spent more than once,in contrast to the prior art system, which allows only a single paymentper "e-coin". A typical transaction of the present invention distinctlyinvolves electronic coins of different denominations moving between twostored-value devices in both ways to account for the desired value. Theelectronic coin pool of the present invention is furthermore distinctfrom the prior art central database in that the electronic coins in theelectronic coin pool are still valid and may be put back intocirculation for further spending, whereas the prior art central databaseis merely a listing of "e-coins" which are no longer valid fortransactions.

Thus, according to the present invention, there is provided a countableelectronic monetary system for the transfer of electronic money inamounts which are an integer multiple of an elementary monetary unit,the transfer of electronic money made between two selected ones from aplurality of payment cards, a plurality of points of sale and a numberof financial institutions, the countable electronic monetary systemincluding:

(a) at least one electronic coin type, each electronic coin type of theat least one electronic coin type having a denomination of an integernumber of the elementary monetary unit;

(b) a plurality of electronic coins each belonging to one of the atleast one electronic coin type, each electronic coin of the plurality ofelectronic coins having a serial number;

(c) a plurality of stored-value devices, each for storing electroniccoins from the plurality of electronic coins, including:

a plurality of electronic coin purses, each included in a payment cardof the plurality of payment cards;

a plurality of electronic coin drawers, each included in a point of saleof the plurality of points of sale; and

a number of electronic coin pools, each included in a financialinstitution of the number of financial institutions;

and transaction means for the transfer of a selectable number ofelectronic coins belonging to a selectable electronic coin type, from asource stored-value device selected from the plurality of stored-valuedevices to another, second stored-value device selected from theplurality of stored-value devices, the transaction means being operativeto record the serial number of each one of the transferred electroniccoins in the target stored-value device and to erase this serial numberfrom the first stored-value device.

Other aspects of the present invention are presented in the detailedspecifications hereinbelow.

BRIEF DESCRIPTION OF THE DRAWINGS

For brevity in the drawings, an electronic coin is denoted by the label"EC" and an electronic bill is denoted by the label "E-Bill"

FIG. 1 is a block and flow diagram illustrating the main elements of abasic form of the payment system in accordance with a preferredembodiment of the present invention;

FIG. 2 is a block diagram illustrating the memory organization inpreferred embodiments of cards and POS according to the presentinvention;

FIG. 3 is a block diagram illustrating the memory organization inpreferred embodiments of financial institution computers according tothe present invention;

FIG. 4 is a table illustrating the calculation of the memoryrequirements for the embodiment of FIG. 1;

FIG. 5 is a block and flow diagram illustrating the structure andoperation of a further preferred embodiment of the present invention;

FIG. 6 is a flowchart illustrating the payment procedure of theembodiment of FIG. 5;

FIG. 7 is a table illustrating the calculation of the memoryrequirements for the embodiment of FIG. 5;

FIG. 8 is a block diagram illustrating in detail the main units of theembodiment of FIG. 5;

FIGS. 9, 9A and 9B are block diagrams illustrating a further preferredembodiment of the present invention;

FIGS. 10A and 10B are tables illustrating the calculation of the memoryrequirements of the cases described in FIG. 9A and 9B, respectively;

FIG. 11 is a block and flow diagram illustrating the structure andoperation of a further preferred embodiment of the present invention;

FIG. 12 is a table illustrating the calculation of the memoryrequirements for the embodiment of FIG. 11;

FIG. 13 is a flowchart illustrating the electronic cash paymentprocedures in the embodiments of FIGS. 9, 11, 14 and 17;

FIG. 14 is a block and flow diagram illustrating the structure andoperation of a further preferred embodiment of the present invention;

FIG. 15 is a table illustrating the calculation of the memoryrequirements for the embodiment of FIG. 14;

FIG. 16 is a block diagram illustrating a farther preferred embodimentof the present invention;

FIG. 17 is a block and flow diagram illustrating the structure andoperation of a preferred embodiment of the present invention;

FIG. 18 is a table illustrating the calculation of the memoryrequirements for the embodiment of FIG. 17;

FIGS. 19 and 20 are block diagrams illustrating the memory organizationin various stored-value device of the present invention, where twoeditions of electronic cash are used simultaneously;

FIG. 21 is a block and flow diagram summarizing the flow of electronicmoney for the various transactions of the present invention;

FIG. 22 is a block diagram illustrating another embodiment of thepresent invention relating to a "semi-countable" feature;

FIG. 23 is a flowchart illustrating the operation of the embodiment ofFIG. 22;

FIG. 24 is a table illustrating the calculation of the memoryrequirements for the embodiment of FIG. 22;

FIG. 25 is a diagram showing the storage of card identification datawith respect to electronic bill serial numbers;

FIG. 26 is a diagram showing a paper confirmation receipt issued by aloading terminal;

FIGS. 27A, 27B, 27C, and 27D are block diagrams showing the operation ofa simple protocol for transferring an electronic coin;

FIG. 28 is a flowchart illustration of the simple transfer protocolillustrated in FIG. 27;

FIG. 29 is a flowchart and block diagram showing a failure of the simpletransfer protocol in FIG. 27 and FIG. 28, resulting in the duplicationof an electronic coin;

FIGS. 30A, 30B, 30C, 30D, 30E, 30F, 30G, 30H, and 30I are block diagramsshowing the operation of a duplication-resistant protocol fortransferring an electronic coin;

FIG. 31 is a flowchart of the duplication-resistant transfer protocolillustrated in FIG. 30;

FIG. 32 is a diagram showing a watchdog according to the presentinvention, based on continuous electronic coin sampling to detectduplicate electronic coins;

FIG. 33 is a diagram showing received electronic cash files and how theyare used to perform an audit;

FIG. 34 is a flowchart illustration showing an example of how acontinuous electronic coin sampling detects the source of a boguselectronic coin;

FIG. 35 is a flowchart illustration showing a recursive method forgenerating a transaction path for an electronic coin.

DESCRIPTION OF THE PREFERRED EMBODIMENTS 1. Electronic Coins andElectronic Coin Transactions

Payment is made in values that are a multiple of an elementary monetaryunit (EMU). Hereinbelow the value of 1¢ is less used as an example ofEMU, although in other countries the practical EMU may have values suchas 5, 10 or 100 units of the lowest monetary denomination.

A basic concept to the present invention is the electronic coin. This isan information entity, which can be stored electronically instored-value devices, and moved between such devices. An electronic coinhas a denomination that is an integer multiple of an EMU, and a serialnumber. Preferably, a serial number will be unique to each singleelectronic coin of a specific denomination; however, a small, predefinednumber of repetitions of the same serial number may be pre-programmedinto the system and allowed. Also, it is noted that the serial numbermay be represented for human reading in any acceptable form such asArabic numerals, letters, etc.; however, its computerized storage willbe in a standard computer storage form, e.g. binary.

According to the present invention, when transferring an electronic coinfrom a stored-value device (the source) to another stored-value device(the target), the serial number of this electronic coin is erased fromthe source and written onto the target stored-value device. Thus,whenever the verbs "move" or "transfer" are mentioned hereinbelow inconjunction with an electronic coin, it should be understood that theserial number of this electronic coin is erased from and written ontothe source and target stored-value devices, respectively. However, theterm "erase", relating to digital storage, is essentially logical andshould be interpreted hereinafter liberally; for instance, erasure maybe implemented by a logical flag indicating that the storage space of anelectronic coin serial number has been freed and is available forstorage of another electronic coin serial number, while the resident"erased" serial number becomes logically inaccessible withoutnecessarily resetting the bits representing this erased serial number.

Electronic coins of different denominations may coexist in the samesystem. In this case, electronic coins having the same denomination willbe referred to hereinbelow as belonging to same "electronic coin type."

2. Payment System Configurations

2.1. Basic Payment System Using Elementary Electronic Coins Only (FIGS.1-4)

An embodiment of a basic payment system based on the present invention,uses a single electronic coin type, having the denomination of one EMU(elementary monetary value), e.g. 1¢. This electronic coin type iscalled the elementary electronic coin, or electronic coin-0.

FIG. 1 is a block diagram describing the main elements of the basic formof a payment system of the present invention, generally designated 1. Apayment card 2 is one of a large plurality of payment cards used byconsumers for payment. Payment card 2 is either in the well-known formof a credit-card-like plastic card with an embedded chip, or in anyother form, such as key-chain, toll-payment transponder, or part of apersonal computer or part of a cellular telephone. Payment card 2includes electronic coin-0 purse 11, which is a stored-value devicecontaining security information and elementary electronic coins in themanner described in FIG. 2. A POS 3 is one of a plurality of points ofsales used by merchants to receive payment from consumers. POS 3 can bea manned or automatic, and can also include means for determining thepurchase contents and calculating the amount due for payment. POS 3includes electronic coin-0 drawer 12, which is a stored-value devicecontaining security parameters and elementary electronic coins in themanner described in FIG. 2. The aggregate of computer systems offinancial institutions, designated 4, includes an electronic coin-0 pool13, which is a stored-value device containing security parameters andelementary electronic coins in a manner described in FIG. 3. A paymenttransaction 7 is executed when card 2 is inserted into POS 3 orcommunicates with POS 3 in any other way (e.g. over the Internet); thispayment transaction moves a specified number of elementary electroniccoins from electronic coin-0 purse 11 to electronic coin-0 drawer 12,each elementary electronic coin transfer including the erasure of thiselectronic coin's serial number from purse 11 and its recording indrawer 12. In settlement transaction 5, POS 3 communicates withfinancial institutions 4, to transfer elementary electronic coins fromelectronic coin-0 drawer 12 to electronic coin-0 pool 13 and claim theirtotal value: the communication between POS 3 and financial institutions4 can be made through telephone or data communication physical orcellular links, through hand-held devices or by physically transferringdrawer 12 to a terminal of financial institution 4. In load transaction6, card 2 communicates with financial institution computers 4,preferable by presenting the card at a terminal connected to computers 4(such as in a bank counter, ATM, special telephone or dedicated homeunit); the consumer then pays a selected amount with an, monetaryinstrument acceptable at that terminal, an equivalent amount ofelementary electronic coins is then moved from pool 13 to purse 11, eachelementary electronic coin transfer including the erasure of thiselectronic coin's serial number from pool 13 and its recording ontopurse 11.

FIG. 2 is a block diagram illustrating the storage of electronic coinsin electronic coin stored-value devices such as purse 11 or drawer 12 ofFIG. 1. A register 21 contains the denomination the electronic coinsstored in this stored-value device. A register 22 stores the currentnumber of stored-value units: multiplying this number by denomination 21yields the total value stored in this storage device. A register 23shows the capacity of the electronic coin stored-value device, i.e. themaximum number of electronic coins which can be stored therein.Registers 24-1 to 24-N include the serial numbers of thecurrently-stored electronic coins, preferable with a few parity bitsadded to each register for ensuring data integrity and security; therest of the registers (24-N+1 to 24-MAXN) include the number zero, whichmeans that no electronic coins are currently stored therein.

FIG. 3 shows an alternative way to store electronic coins, which isaimed at storing a vast number of units, typically at electronic coinpool 13. A register 31 includes the denomination of the storedelectronic coins. A register 32 stores the parameter FIRST, which is thelowest serial number of an issued electronic coin of said denomination(e.g. 1), while a register 33 stores the parameter LAST, which is thehighest number of an issued electronic coin of said denomination.Registers 34-1 to 34-M form a vector of length M=LAST-FIRST+1 composedof bits, wherein each issued electronic coin corresponds to a bit by theformula SERIAL NUMBER=BIT ADDRESS+FIRST-1. Whenever an electronic coinis removed from pool 13 (e.g. for loading purse 11), the correspondingbit is turned off; when a specific electronic coin is added to pool 13(e.g. through settlement with drawer 12), the corresponding bit isturned on. In a configuration mentioned above where a small multiple Kof each serial number is allowed, the vector is replaced by a matrix of(LAST-FIRST+1) by K dimensions. Any attempt to turn on an already-onbit, will indicate that there is an invalid electronic coin in thesystem. This provides a simple, low-cost, and efficient means formonitoring the system's security, which is a main objective of thepresent invention.

FIG. 4 presents a table with numerical calculations, relating to theembodiment under consideration, and to reasonable assumptions aboutnationwide implementation in the U.S. market. Assuming 150 million cardsin circulation (41-1), and $200 in units of 1¢ being the capacity oneach card (41-2), and assuming that the total electronic cash in thesystem can be estimated by the total card capacity (in a realisticsnapshot, most cards are only partly loaded, but money is also stored inPOS and cash pools), we obtain that the total number of 1¢ electroniccoins is 3*10¹² (41-3). A serial number for this range requires 42 bits(41-4). Adding 3 bits per serial number for parity check (41-5) yieldsthe need for 45 bits per each stored elementary electronic coin, whenstored on payment cards 2 or POS 3 according to the storage scheme ofFIG. 2. This requires to reserve on each purse 11 (which may contain upto 20,000 electronic coins) 900,000 bits (41-7) or 112,500 bytes (41-8).Assuming that the merchant wishes to accumulate $1,000 of electroniccash prior to performing a settlement transaction with a financialinstitution, he has to reserve in drawer 12 memory for 100,000electronic coins (41-9) which requires 562,500 bytes (41-11) per POS.The cash pool, needing to monitor 3*10¹² electronic coins, will require(when applying the storage scheme of FIG. 3) this number of bits, or375*10⁹ Bytes (41-12), which is about 350 GB.

The numeric results of FIG. 4 show that the memory requirements are verydemanding for the card and also for many types of POS. Also, payment,settlement and load transactions may take unacceptable average andworst-case times because of the large amount of dataflow.

The following, alternative embodiments will show ways to reducedramatically the memory and dataflow requirements, thus simplifying,increasing the reliability and reducing the cost of the presentinvention's implementation.

2.2 A Payment System with Charge and One Electronic Coin Type (FIGS.5-8)

FIG. 5 is a block diagram illustrating schematically the main element ofa preferred embodiment of a payment system according to the presentinvention. More information on the operation of this embodiment isavailable in co-pending U.S. patent application Ser. No. 08/533,599 ofSep. 25, 1995, and in an equivalent PCT publication WO 96/09592.

Payment card 51 includes charge card 51-C and electronic coin-0 purse51-0 for accommodating elementary electronic coins having the value ofone EMU (elementary monetary value). Similarly, POS 52 includes chargedrawer 52-C to temporarily store therein charge orders made in off-line,and electronic coin-0 drawer 52-0 to store therein elementary electroniccoins. The computer system of financial institution 53 includes charge(credit and/or debit) accounts 53-C, and electronic coin-0 pool foraccommodating elementary electronic coins.

Reference is now also made to FIG. 6, to illustrate the paymentprocedure with the embodiment under consideration. A primary conceptrelating to this embodiment is a parameter $LIMIT, usually defined bythe card issuer or the merchant, to specify the minimal amount allowedfor charge transactions, e.g. $25.

When a payment card 51 with current amount of $BALANCE in its electroniccoin-0 purse 51-0 interfaces with POS 52 (step 61) to pay an amount of$SUM, $SUM is compared to $LIMIT (step 62) to decide whether the paymentcan be made via charge card 51-C (step 64 transaction 54). If not,payment is referred to purse 51-0. In step 63, $SUM is compared to$BALANCE to find out whether payment can be made from the amount storedin the purse (step 65, transaction 55); if not (step 66). $LIMIT will bepaid by charge card 51-C to charge drawer 52-C, and change of$LIMIT-$SUM is transferred from drawer 52-0 to purse 51-0 (transaction56).

The payment procedure of FIG. 6 has the following advantages:

(a) payment can always be made for any amount, limited only by thecharge card's ceiling; no manual loading of purse 51-0 is ever requiredin this embodiment;

(b) the value stored in purse 51-0 will not exceed $LIMIT, whichminimizes the damage in case of loss;

(c) for any specific POS 52, the average amount of electronic coininflow through payment transaction 55, equals the average amount ofelectronic coin outflow through change transaction 56. This means thatelectronic coins actually revolve among cards and POS.

Returning now to FIG. 5, in settlement transaction 57, charge ordersreceived from customers through transactions of steps 64 and 66 of FIG.6 are submitted for clearance with the respective accounts in chargeaccounts 53-C. Transaction 59 provides the initial amount of electroniccoins to a payment card, prior to supplying the card to the customer. Inthe embodiment under consideration, no additional transfer of electroniccoins between financial institutions and customers is ever needed. Intransaction 58, four procedures are carried-out regarding electroniccoin flow between the POS 52 and financial institution 53:

(a) Priming: as electronic coin drawer 52-0 must always have sufficientamount of electronic coins for returning change to purse 51-0 (step 66of FIG. 6), some amount of initial electronic coins must be supplied tothe drawer before starting a business cycle (e.g. a workday); thisamount is acquired by the merchant from the financial institution andtransferred from pool 53-0 to drawer 52-0. Priming with about 15% of theexpected electronic coin revenue during the business cycle proves to beeffective for flawless operation with very high probability.

(b) Adjustment: at the end of the business cycle, the amount ofelectronic coins in electronic coin drawer 52-0 is expected,statistically, to be unchanged in respect to the initial amount.However, due to statistical fluctuations, the actual amount wouldusually require small addition or subtraction in order to start the nextbusiness cycle with a predefined amount of electronic coins for priming.

(c) Monitoring: in order to check the security of the system at pool53-0, an amount of flow from drawer 52-0 must be ensured. The naturalflow through adjustment transactions might be sufficient, or someadditional exchange of electronic coins between drawer 52-0 and pool52-0 may be initiated during the routine communication between the POSand financial institution, made for other transactions from 57 and 58(monitoring is discussed in greater detail hereinbelow).

(d) Refresh: if both an old and a new edition of electronic coins areused, old electronic coins can be intentionally drained from POS tofinancial institution during routine communication (refreshing isdiscussed in greater detail hereinbelow).

It is noted that all transfers of electronic coins described above,through transactions 55, 56, 58 and 59 of FIG. 5, involve moving theserial number of each transferred electronic coin, as described withreference to FIG. 1 to which reference is now made.

FIG. 7 calculates the amount of storage and transfer of informationneeded for the implementation of the embodiment under consideration.Assuming 150 million cards (71-1) (as in FIG. 4), accommodating up to$25 each, which are 2500 1¢ electronic coins (71-2). The total number ofcoins is estimated as the total number of cards multiplied by eachcard's maximal capacity (actually, half of this amount will reside oncards, while the remainder will be in POS drawers and financialinstitution pools), which leads to 375 billion electronic coins (71-3)which require 39 bits for a unique serial number (71-4). Adding 3 paritybits, we obtain 42 bits per each electronic coin serial number. For 2500electronic coins, this means 13,125 bytes per payment card. A POSaccommodating up to $1000 in 1¢ electronic coins will require 525,000bytes of memory for recording their serial numbers (71-11), while a cashpool allocating 1 bit per electronic coin (memory management accordingto FIG. 3), will need 48,875 million bytes (71-12).

The memory requirements represented by the results of FIG. 7 are easilyacceptable to financial institutions and POS, and feasible, yet stilldemanding, for cards. Further reduction of the data storage and flowrequirements will be described in the embodiments hereinbelow.

Reference is now made to FIG. 8, which is a detailed block diagramillustrating in more detail the embodiment of FIG. 5. Payment card 51includes elementary electronic coin purse 51-0 and charge card 51-C.Purse 51-0 includes an electronic coin denomination register 51-D, atotal balance register 51-B and a memory 51-L accommodating the serialnumbers of all electronic coins currently stored in purse 51-0. Chargecard 51-C includes an account info register 51-A with the informationrequired to access and perform transactions with the respective accountfrom charge accounts 53-C at respective financial institution 53.External interfacing 51-E allows card 51 to interface with points ofsale 52, through interface means which may use contact, contactless orremote communication links. POS 52 includes a card interface 52-2 tointerface with payment cards 51 and a customer interface 52-4 to allowthe customer to key-in parameters such as a PIN code for chargetransactions. A payment amount register 52-3 receives the payment amountfrom a calculation unit 52-6 which determines the purchase contents andits price by receiving signals from a purchase interface 85, which maybe a keypad, bar-code scanner, vending machine controller etc. Anautomatic transaction manager 52-1 performs the transaction procedure ofFIG. 6 upon receiving the amount due from register 52-3 and theelectronic coin purse parameters from card interface 52-2. Automatictransaction manager 52-1 activates: an electronic coin payment unit 52-8to receive payment from purse 51-0 and deposit the payment in electroniccoin drawer 52-0; an electronic coin change loading unit 52-10 to returnchange to electronic coin purse 51-0 from drawer 52-0; and a chargetransaction unit 52-7 to charge the respective account in chargeaccounts 53-C in accordance to charge card 51-C. Charge drawer 52-Caccommodates charge transaction orders until settled with financialinstitutions 53. The computer system of financial institutions 53maintains charge accounts 53-C and electronic coin pools 53-0, fortransactions 57, 58 and 59 of FIG. 5.

2.3. A Payment System with Charge and Two Electronic Coin Types (FIGS.9-10)

The embodiment illustrated in FIG. 9 to which reference is now made,reduces the amount of data storage and transfer, in comparison to theembodiment of FIG. 5 described hereinabove. In this embodiment, anelectronic coin purse 91-s is subdivided into an electronic coin-0 purse91-0 containing elementary electronic coins of one EMU value, and anelectronic coin-1 purse 91-1 containing electronic coin-1 coins, whosedenomination is a predefined integer number of EMU (elementary monetaryunit). An electronic coin drawer 92-S and an electronic coin pool 90-Sare subdivided similarly. Each sub-stored-value device can contain onlythe respective type of electronic coins, and electronic cointransactions between devices transfer electronic coins only betweenmatching sub-stored-value devices.

The transaction procedure for multiple electronic coin type purses willbe described hereinbelow:

The embodiment of FIG. 9 operates with similar efficiency to theembodiment of FIG. 5. The purse subdivision can be left transparent tothe card holder and merchant.

Each electronic coin sub-level perform individually with a similarbehavior as the single electronic coin level of FIG. 5. Thus, the inflowand outflow of electronic coins at each sub-level are statisticallyequal in average.

FIG. 9A describes a $25 charge transaction minimum limit using theprocedure) and an electronic coin purse subdivided to accommodate amaximum number of 24 $1 electronic coins and 99 1¢ electronic coins. Thequantities 24 and 99 are determined according to criteria describedhereinbelow. These quantities are exemplary without in any wayrestricting the scope of the invention. FIG. 10A calculates the amountof data needed to be stored and transferred during transactions. It canbe seen the card now needs only 563 bytes for electronic coin storage,the POS makes do with 8,956 bytes, and the financial institution can nowuse even a personal computer for storing the entire electronic coin poolstatus.

FIGS. 9B and 10B are similar to FIGS. 9A and 10A respectively using 50¢electronic coins (instead of $1 electronic coins for electronic coin-1.)

2.4. A Payment System with Three Electronic Coin Types (FIGS. 11-12)

FIG. 11 illustrates electronic coin storage, using a payment card and anelectronic purse and allowing automatic payment and change transactionsat the POS according to FIG. 6. functions, without including chargefunctions in the transaction options.

The rules for establishing and operating a multiple electronic coin typesystem are described hereinbelow, FIG. 11 illustrates a system, whereeach payment card can accommodate any amount between 0 to $199.99 inelectronic coins of $10, $1 and $1¢. (These values are not optimal;actually, for a $200 purse, electronic coins with denominations of$7.84, 28¢ and 1¢ would yield even better results but could beconfusing.) The results shown in FIG. 12, show that for 150 millioncards, each carrying a maximum of almost $200, 581 bytes on the cardwould be sufficient for storing all electronic coins, while minimalstorage requirements are expected also from the POS and financialinstitution computers.

An additional important aspect, shown in FIG. 11, is the loadingdoctrine. Loading in a "pure" stored-value card, i.e. a card without acharge function, requires payment by any means to a terminal connectedto the financial institution, and transferring electronic coins (eachwith its serial number) therefrom into the respective sub-purse. It isboth reasonable and efficient to allow such load transactions only withthe higher denominations of coins or even with the single highestdenomination. Electronic coins of denominations allowed for loading willalso be called electronic bills, and their respective storage devicewill be presented in the drawings as a rounded-corner square (see 111-2,112-2 and 110-2 of FIG. 11.) As bill be illustrated hereinbelowelectronic bills revolve mostly in the circle pool-purse-drawer-pool,the lower electronic coins (not permitted for loading) revolve mostlybetween purses and drawers.

2.5 A Payment System with Multiple Electronic Coin Types (FIGS. 13-15)

A multiple electronic coin type system is devised to allow payment ofany multiple integer of EMU (elementary monetary unit), with a smallnumber of electronic coins. Following is a description of such a systemusing J+1 types: electronic coin(0) . . , electronic coin(J), ofdifferent denominations SD(0) . . . SD(J), assuming monotonic ascendingorder. All values described hereinafter are in terms of a common,minimal monetary unit, e.g. 1¢; thus $200 is actually represented as20,000¢.

The following parameters are preferred for optimal operation:

(a) $D(0) equals one EMU.

(b) R(I)=SD(I+1)/$D(I) is an integer>1 for all 0≦I≦J-1.

(c) The memory space allocated in the payment card for electroniccoin(I) is R(I)-1 for 0≦I≦J-1. For electronic coin(J), the allocatedspace is arbitrary and is the main factor determining the maximum valuethat can be stored on the card.

(d) The amount of electronic coins of each electronic coin type storedin the POS is considered to be practically infinite.

(e) Payment with electronic coins is executed according to the procedureof FIG. 13, which will now be described.

FIG. 13 is a flowchart describing the payment procedure in a multipleelectronic coin type system constructed according to the above rules. Astatement 130 repeats the rules. In a step 131, a purse containing valueof $INPURSE(I) for each type I (e.g. if electronic coin(3) type has thevalue of 300¢ and there are 7 electronic coins of this type. $INPURSE(3)will have the value of 2,100.), is presented to pay an amount $AMOUNT(also expressed in 1¢ units). In a decision point 132, the pursecontents is checked to see if there is sufficient value for payment. Ifthe answer is "no" step 133 checks for alternative options (e.g. if thecard contains a charge card, then the payment alternatives 64 or 66 ofFIG. 6 may become valid.), or payment is rejected. Otherwise, in step134-1, an artificial denomination $D(J+1) is set as infinity (to ensureproper completion of loop and stop at 138 for higher payments; actually,any value larger than $AMOUNT+$D(J) will suffice as "infinity") and thenloop 134 through all integer values of 1 from 0 to J starts. In a step135 the payment $PAY required to be made by electronic coin (I) iscalculated, by checking what amount cannot be paid b) the next higherdenomination $D(I+1). In decision point 136, $PAY is compared to theavailable money in this type of coins $INPURSE(I). If the availablemoney is sufficient, this amount is paid in step 136-1 by moving thecorresponding amount of electronic coin(I) units (each moving with itsserial number) from the payment card to the POS. If the amount isinsufficient, then in step 136-2, $AMOUNT is increased by the one nexthigher monetary electronic coin denomination $D(I+1) and in step 136-3,this transaction is compensated by crediting the card with an amount$D(I+1) in an equivalent amount of electronic coin(I) units. However, as$PAY still needs to be deducted, the end result is a change transaction136-3. Each electronic coin moved is transferred from the POS to thecard with the electronic coin serial number. In step 137, the payment ofamount $PAY is deducted from the amount due $AMOUNT, and the procedurecontinues with the next higher denomination, until completion at exitstep 139 from decision point 138.

As mentioned above, in the case that the sum of all $INPURSE(I), checkedat decision point 132, is insufficient, it may still be possible tocomplete the payment by means of a charge transaction, as indicated instep 133, and as also shown in step 66 (FIG. 6). When a chargetransaction is carried out in order to make a payment less than theminimum charge amount, the charge transaction will be for the minimumcharge amount, and the difference between this minimum charge amount andthe desired payment will be returned to the payment card as chance inthe form of electronic coins. As previously mentioned, however, it isnot possible to send an arbitrary number of electronic coins ofarbitrary denomination to the payment card, because the capacities ofthe individual purses for the different electronic coin denominationsare limited. For example, if the 1¢ purse is already filled, then it isnot possible to send any 1¢ electronic coins to the payment card. Ingeneral, then, sending change to the payment card in the form ofelectronic coins involves a combination of transfers of electronic coinsfrom the POS to the payment card coupled with transfers of electroniccoins from the payment card to the POS. To calculate the correctcombination of electronic coins which must be transferred in eachdirection, it is possible to use the same algorithm described above andillustrated in FIG. 13 as follows:

First, it is necessary that the minimum charge amount be equal to thelargest electronic coin denomination multiplied by 1+the number of thoseelectronic coins which the payment card can hold. For example, if thelargest electronic coin is worth $5 and the payment card can hold 4 ofthem, then the minimum charge amount must be $25. This is an easycondition to implement, because the minimum charge amount can easily beadjusted upwards to suit the denominations and capacities of the paymentcard. For example, if the largest electronic coin is worth $7 and thereare 5 of them, then the minimal charge would simply be set at $42. Then,using the algorithm illustrated in FIG. 13, the charge is considered asif it were a "virtual" electronic coin sent from the payment card to thePOS. Because there is this additional "virtual" electronic coin, thenumber of electronic coin denominations is therefore increased from J+1to J-2, where EC(J+1) is the charge (the "virtual" electronic coin) and$D(J+1) is the minimum charge amount. With these conditions met,application of the algorithm (described above and illustrated in FIG.13) will result in a transfer of electronic coins such that the paymentcard will receive the proper change while observing the limits on thenumber of electronic coins permitted for each denomination.

The set of rules specified above, as well as the flawless operation ofthe payment procedure of FIG. 13, are based on elementary mathematicalconsiderations. The general problem of selecting objects representingdistinct integer values in such a way that their values add up to aspecific sum is well-known in the mathematical literature, and isreferred to as the "subset sum problem" (sometimes referred to as the"knapsack problem"). It is known that if the represented values (in thiscase, the denominations of the electronic coins) are predeterminedrandomly, then the problem is difficult to solve and may not have asolution for every desired sum. On the other hand, if the set ofrepresented values is chosen according to certain conditions, then notonly will there always be a solution, but the solution will be very easyto find. The condition which assures that the solution will be easy tofind is simply that each object must represent a value greater than thesum of all smaller objects. A set conforming to this condition is knownas a "superincreasing set", and the solution, if it exists, can bequickly found by comparison and iteration (as shown in the examplesfollowing). The condition which assures that a solution will always befound is simply that each object must represent a value 1 greater thanthe sum of all smaller objects. A set conforming to this condition isknown as a "minimal superincreasing set". For example, the set {1, 3, 5,5, 5, 23, 47} is a superincreasing set. To find the elements of the setwhich add up to 34 is easy. First of all, 47 is too large to be presentin the subset, but 23 is in the subset. Subtracting 23 from 34 leaves11. Then it is seen that 5 must be in the subset, leaving 6. Another 5must also be in the subset, leaving 1. Finally, 3 is too large to be inthe subset, and it is seen that the final element in the subset is 1,leaving 0 left over, showing that 34 has a solution. The desired subsetis then {1, 5, 5, 23}. On the other hand, there is no solution for a sumequal to 7. As another example, the set {1, 1, 1, 1, 5, 10, 10, 10, 10,50, 100} is a minimal superincreasing set for which solutions exist forevery sum from 1 to 199. An arbitrary number in this range such as 137can easily be expressed by the subset {1, 1, 5, 10, 10, 10, 100} usingthe same iterative steps as before. Minimal superincreasing sets areeasy to generate by observing the conditions given above. It is readilyseen that, in order to function properly, the electronic coin purses ofa payment card must constitute a minimal superincreasing set. Somemathematical references which discuss the subset sum problem in detailinclude Cipher Systems, by Henry Beker and Fred Piper,Wiley-Interscience, 1982, pages 373-380; and Applied Cryptography, byBruce Schneier, John Wiley, 1994, page 278.

For best results (i.e. minimal memory requirements in the system, andspecifically on the card), two additional rules are preferable:

(1) The ratio factors R(I) would be set equal to each other (this is thereason for 10B bettering 10A).

(2) The number of purses, i.e. J+1, should be maximal but not exceedingthe capacity needed to be stored on the card.

Combining these two rules, we obtain the most efficient configuration,which is a binary card with electronic coin denominations of 1EMU, 2EMU,4EMU, 8EMU etc., each having a single accommodation on the payment card.The following example, in FIGS. 14 and 15 demonstrates the efficiency ofa binary card.

FIG. 14 illustrates an embodiment of a payment system according to thepresent invention, where each stored-value device includes 16 electroniccoin sub-storage-devices, for denominations of 1¢, 2¢, 4¢ . . . 32768¢.The payment card can accommodate a single electronic coin for eachdenomination; the POS and financial institution accommodate a pluralityof each. The three highest electronic coin values are selected to havealso an electronic bill function, i.e. the card bearer is allowed tomake manual loads for values that are an integer multiple of $81.92.When operated according to the procedure of FIG. 13, transactionstatistics described hereinbelow with reference to FIG. 21 teaches thatthe highest electronic coin type ($327.68) will revolve in the cyclepool-purse-drawer-pool; the other two electronic bills ($163.84 and$81.92) will revolve in this cycle with some percentage also in thepurse-drawer-purse cycle, depending on the typical loading pattern ofconsumers (the more consumers tend to load higher electronic billvalues, the more electronic bill change of smaller electronic billvalues will be observed.) The smaller electronic coins (1¢ to $40.96)will revolve in the cycle purse-drawer-purse.

FIG. 15 calculates the storage requirements for the binary scheme ofFIG. 14, for 150 million cards (150-1). The card may accommodate up toone electronic coin of each type, which leads to the estimate of 150million electronic coins of each type (150-3), requiring 28 bits for aunique serial number for each electronic coin belonging to a specifictype (150-4). Adding 3 parity bits (150-5), we obtain 31 bits per type(150-7). Multiplying this number by 16 for the 16 types, and dividing by8 to convert from bits to bytes, the rock-bottom requirement of 62 bytesper card is obtained. Assuming that a POS is required to provide spacefor 100 coins of each type, 6,200 bytes of memory will be required foreach POS (150-11). As each electronic coin requires a single bit at thefinancial institution's pool (FIG. 3), 150,000,000 cards multiplied by16 types and divided by 8 (for bit-to-byte conversion) yield the numberof 300,000,000 bytes storage requirement (150-12) at the pool, which iseasily provided by any personal computer's disk.

2.6. A Payment System with a Mixture of Card Types (FIG. 16)

A single payment system according to the present invention may serve avariety of card types. FIG. 16 illustrates a single payment system. Inaccordance With the preferred embodiment of the present invention anumber of electronic coin types are selected for the entire system,according to the rules of described hereinabove. The highest electroniccoin level is selected in this embodiment to serve also as electronicbill. That is, manual loading an integer multiple of this coin isallowed. Each POS 160 has a charge drawer and a number of electroniccoin drawers according to the system-level selected electronic cointypes. Another type of POS 161 omits the charge card function, e.g. forvending machine applications. A computer system of financial institution162 has charge accounts and a number of electronic coin pools accordingto the system-level selected electronic coin types. The system serves avariety of payment cards, including electronic coin-0 purses 163 (seealso FIG. 1), combination charge/purse cards 164 with auto-reloadfunction (see also FIGS. 5 and 9), multi-stage "pure" purse cards 165where reloading is limited to the higher value electronic coins only(see also FIGS. 11 and 14). The system also serves payment cards 166,where the card allows reloading by either manual reload of theelectronic bill purse (such an intentional reload is important if theconsumer wishes to make purchases under absolute anonymity and privacy),or automatically from his charge card according to the scheme of FIG. 6,for maximum convenience.

2.7. The Recommended Payment System (FIGS. 17-18)

The choice of a "preferred" configuration depends on the needs andpreferences of specific environments. One major consideration isefficiency, the other major consideration being friendliness. Forexample, the most efficient binary, 16-stage system illustrated abovewith reference to FIG. 16, may be hard to understand to many, and therequired reload of integer multiples of $81.92 may be strange andinconvenient.

FIG. 17 presents a recommended, multiple stage payment system,constructed according to the rules described hereinabove. Its operationaccording to FIG. 13 enables two reload options for the customer choice:automatic reload from the charge card according to FIG. 6 for maximumconvenience (this will also keep the total electronic coin value under$25), or manual load with integer multiples of $25 for maximum anonymityand privacy (with a maximum purse capacity of $274.99.) Although not anoptimal (binary) division among the electronic coin denominations, theselected values show a very efficient performance (FIG. 18), whilemaking use of denominations that are practical to use and easy tounderstand, as they resemble real-life denominations of conventionalcoins and bills. (It would be appreciated, however, that except for loadtransactions, the entire division into separate denominations is merelya technical aspect, which may be kept transparent to consumers andmerchants.)

FIG. 18 calculates the storage requirements for the configuration ofFIG. 17. The different electronic coin denominations are grouped in line180-1 according to their multiplicity 180-4, taken from 171 of FIG. 17.The number of cards in circulation 180-3 is assumed to be 150 million.The total number of electronic coins is estimated as the total capacityof all cards (actually, cards are expected to accommodate about 50% ofthis capacity, while the remainder being distributed among POS andfinancial institution computers). Line 180-5 calculates the total numberof electronic coins for each of the group members of line 180-1, bymultiplying the values from lines 180-3 and 180-4. The number of bitsneeded for a unique serial number for each card type is calculated in180-6, and 3 parity bits added at 180-7 to yield the result at 180-8.The size of each group (see 180-1) is presented in line 180-10, formultiplying the numbers from line 180-9 to yield the total number ofbits for each group. The total number of bits is summarized in line180-12, and converted to bytes in line 180-13.

The POS calculation estimates preparing room for 100 electronic coinsfor each denomination, except the $25 denomination where room for 200electronic coins is provided. Line 180-14 shows the room for the entiregroup. When multiplied by the number of bits per each electronic coinfrom line 180-8, the number of bits is obtained in 180-15, to besummarized in 180-16 and converted into bytes in 180-17.

The financial institution calculation multiplies the total number ofelectronic coins 180-5 by group size 180-4 divided by 8 (bit-to-bytefactor) to yield line 180-18 which is summarized in 180-19.

The numbers derived from FIG. 18 show very reasonable data storage andtransfer requirements for a system with 150,000,000 cards, which issufficient to cover the entire U.S. needs. Expanding the same system toa mammoth 5 billion card system, will result in requiring 137 bytes percard, 3,775 bytes per POS, and about 17 GB for the financialinstitutions computer system; these numbers reconfirm the feasibility ofthe present invention for implementation in any desired scale.

2.8. Transaction Statistics

In the specifications relating to FIGS. 5, 9, 11, 14 and 17, it has beenstated that the amount of electronic coins of a specified value flowingfrom cards to a POS as payment, equals in average to the amount ofsimilar electronic coins flowing from same POS to cards as change.

Reference will be made now to FIGS. 5 and 6, and the detailed rulesdescribed above, the focus being on decision 63 and transactions 65, 66.

A first important conclusion is that the amount of stored value($BALANCE) will be maintained smaller than $LIMIT. Even if initially$BALANCE is of a larger value, transactions 65 will deplete the purseuntil the purse contents is smaller than $BALANCE. Then, in the nexttransaction, $BALANCE will be either further depleted by 65, orincreased by adding change through transaction 66. However, an amount of($LIMIT-$SUM), added to $BALANCE in 66, equals $LIMIT-($SUM-$BALANCE),which is smaller than $LIMIT under condition 63.

A second important point is that, after a large number of transactionswith many purses and many POS (and since neither the consumer nor themerchant have any influence or preference regarding $BALANCE), the valuewill be a random number evenly distributed between zero and 1 EMU lessthan $LIMIT.

Therefore, the decision in 63 will yield probability of $SUM/$LIMIT(which is the probability of 63 to be false) to transfer ($LIMIT-$SUM)from the POS to the card, and probability of (1-$SUM/$LIMIT) to transfer$SUM from the card to the POS. The expected value of both directions(obtained by multiplying the transferred value by its probability) isidentical, which proves the claim that, on average, pay 55 and charge 56equal each other.

An analogous discussion with FIG. 13 yields similar results, based uponan analogy between: FIGS. 13=>6: decisions 136=>63; transfers 136-1=>65and 136-3=>66; and values $PAY=>$SUM, $D(I+1)=>$LIMIT and$INPURSE(I)=>$BALANCE; respectively. This explains why electronic coinsactually revolve between electronic coin purses and electronic coindrawers of the same denominations, in all transaction levels of FIGS. 9,11, 14 and 17 which do not allow manual reload.

3. Editions of Electronic Coins (FIGS. 19-20)

One of the well-known attacks on security schemes is through repetitiveattempts to guess the security parameters. The present inventionprovides an effective countermeasure: issuing a new edition ofelectronic coins, with a new set of security parameters, periodically(say, each six months), setting an expiration date of the previousedition for a reasonable time after the new edition issues (say, anotherfour months), and devising means at all transaction levels to drainpayment cards and POS from electronic coins of the previous editionduring all transaction types. These electronic coins are directed intothe respective edition's cash pool, where each electronic coin iscounted and accounted for. At the expiration date of the edition, thevalue of all electronic coins that have not been claimed (i.e. all oldedition's electronic cash that has been lost or abandoned by cardholders) is counted and can be accounted for accurately, which isanother object of the present invention.

FIG. 19 illustrates data organization in an electronic coin purse forsharing the allocated memory for a specific electronic coin type betweentwo electronic coin editions. A register 192 stores the denomination ofthe electronic coin type, while register 193 stores the maximum numberof electronic coins of the respective type, which can be stored in thecard. Referring to the two editions as "A" and "B", registers 194 and197 contain the security parameters (passwords, signatures, etc.)related to the two editions, registers 195 and 198 include therespective expirations dates while registers 196 and 199 contain thenumber of electronic coins currently stored from each edition. Registers190-1 to 190-NA and 191-1 to 191-NB contain the serial numbers for theelectronic coins currently stored in the purse. In this way, a minimalmemory space (even for a single electronic coin, such as for 50¢electronic coins in card 171 of FIG. 17) can be effectively dividedbetween two editions effectively. At the POS drawer level, a similartechnique can be used to divide the memory space between the twoeditions, while at the financial institution pool, the two editions arepreferably managed separately. FIG. 20 shows a two-edition electroniccoin storage of 1¢ electronic coins (register 200), similar to thestorage technique of FIG. 3. Registers 201, 202, 205 and 206 contain thelimits of issued electronic coins for each edition, registers 203 and207 contain the security, parameters for each edition, and registers 204and 208 include the respective expiration dates.

Preferably, whenever electronic coins have to be transferred betweencards and POS or between POS and financial institutions, those from theolder edition will be selected first, while transfers in the oppositedirections, will prefer electronic coins from the newer edition. Thiswill effectively refresh the electronic cash in circulation by drainingcards and POS from the older edition's electronic coins and moving themto the electronic coin pools.

4. Money Flow and System-Level Control (FIG. 21)

Preferably, when a monetary system of the present invention isestablished, all electronic cash will be generated and deposited in oneor more electronic coin pools. Then, prior to supplying a new paymentcard to a consumer, this card will be preloaded by transferringelectronic coins from an electronic coin pool to the card. A POS joiningthe system, will be initially primed with a specified amount ofelectronic coins, to ensure its flawless operation. After theseinitializations, electronic money will flow through various transactionsas described below.

The way money flows in the system of the present invention isdemonstrated in FIG. 21, in reference to the embodiment of FIG. 17 andthe payment procedures of FIGS. 6 and 13.

An electronic bill flow 210 from a pool to a purse occurs when a manualreload of electronic bills (i.e., higher-denomination electronic coinsallowed for manual reload) is executed by the user. An electronic coinpool-to-purse load 211 for lower-denomination electronic coins occursonly once per each card, prior to supplying the preloaded card to theuser. An electronic bill flow 212 and a charge orders flow 213 from cardto POS take place to pay for higher-cost purchases or to automaticallypurchase smaller-denomination electronic coins (blocks 66 in FIG. 6 and136-2 & 136-3 in FIG. 13). The POS will communicate from time to timewith the financial institution, to initiate a charge order flow 219 andan electronic bill flow 218, for settlement. Electronic coins of smallerdenomination than electronic bills, actually revolve between cards andPOS: at each small purchase, electronic coins flows from the card to thePOS as payment (214) or from the POS to the card as change (215). It hasbeen shown in §2.8 above, that statistically, for each electronic coindenomination, the average flows in both direction are equal, whichexplains the usage of the term "revolve".

Electronic coins flow (217 and 216) between POS and financialinstitutions for various purposes:

(a) Priming the POS, before staring a business cycle, with a sufficientamount of each electronic coin type, for having sufficient change tocompensate for statistical fluctuations (see 58 in FIG. 5).

(b) Emptying the POS from electronic cash at the end of a business day,if so desired by security consideration or required by law.

(c) Adjusting the amount of electronic coins in the POS between the endof a business cycle and the beginning of the following one; this may berequired if the POS is not emptied at the end of a business cycle, tocompensate for statistical fluctuations which may cause the amount ofelectronic coins of each denomination to be substantially below or abovethe desired amount at the beginning of the next business cycle.

The two electronic coin cycles (214/215 and 216/217), althoughtransferring on the average a zero monetary value, cause a continuousdiffusion and mixing of electronic coins among financial institutions,POS and cards. This mixing process has two very important roles:

(a) Security: the mixing process allows a continuous sampling, at thefinancial institutions' electronic coin pools, of the electronic coinsin circulation, to identify invalid electronic coins of each type. Suchinvalid electronic coins are identified by finding serial numbers out ofthe issued range (32 and 33 of FIG. 3), or by finding a forbiddenrepetition of the same serial number. When finding such invalidelectronic coins, the mixing process reveals either a system malfunctionor a breakdown of security. Also, the number of such invalid electroniccoins and the size of the sample, provide a reliable estimate to theoverall damage size.

(b) Refreshing: the mixing process allows effectively replacing an olderelectronic coin edition with a newer one by preferring flow of olderelectronic coins in the direction of the financial institution.

To enhance the effectiveness of the electronic coin mixing at both thecard-POS and POS-financial institution levels, the purse-drawer anddrawer-pool transaction procedures will preferably include also thefollowing routines:

(a) The picking of each electronic coin of certain edition and type fortransfer from one stored-value device to another, will be made accordingto preselected picking criteria, such as first-in-first-out orrandom-picking.

(b) A forced-exchange feature will allow exchange of an equal,selectable number of electronic coins of i selected denomination betweentwo communicating stored-value devices; this will allow the systemoperator, during normal, routine transactions and transparently toconsumers and merchants, to accelerate the draining of an older editionand/or to increase the efficiency and reliability of the securitysampling process described above. When used for accelerating therefreshing, such forced exchange will move a selectable number of anold-edition electronic coins of a selected denomination from a purse toa drawer or from a drawer to a pool, while moving the same number of anew-edition electronic coins of the same denomination, from the drawerto the purse or from the pool to the drawer, respectively. Whenrefreshing, devices establish a priority of the transfer of electroniccoins of a first edition with respect to the transfer of electroniccoins of a second edition, where the priority depends on the directionof transfer with respect to the financial institution. If a first devicemakes a transfer to refresh a second device that is more "distant" (interms of the device hierarchy) from the financial institution, the firstdevice sends a new electronic coin to the second device and receives anold electronic coin in exchange. In this way, the old electronic coinshave a preferred movement back to the financial institution, where theyare collected and retired from circulation. In contrast, when used foraccelerating the mixing, a selectable number of electronic coins of thesame edition and denomination will be exchanged between a purse and adrawer or a drawer and a pool, on a first-in-first out or random pickingbasis at each stored-value device.

Following is an example of forced exchange, with respect to theembodiment of FIGS. 17 using the procedure of FIG. 13. Suppose that apayment card performing a payment transaction currently accommodates twoold and two new 10¢ electronic coins ("old" and "new" referring toeditions,) and two old and two new $1 electronic coins, and according tothe procedure of FIG. 13, one 10¢ electronic coin and no $1 electroniccoins have to be transferred to the POS. According to criteriadownloaded to the POS from the financial institution during a previoustransaction, the POS now takes from the card two old and one new 10¢electronic coins, and returns two new 10¢ electronic coins; the POS alsotakes from the card one old and once new $1 electronic coins, andreturns two new $1 electronic coins. By these forced exchanges, bothedition refreshing and coin mixing are accelerated. Similar forcedexchanges are executed during routine transactions between POS andfinancial institutions.

4.1. Duplication-Resistant Electronic Coin Transfer Protocol

Throughout the embodiments of the present invention there is theprinciple that electronic coins may not be created within a payment cardor POS, and, as described herein, the system has features thatstatistically monitor the electronic coin pools to detect duplicateelectronic coins. If no duplicates are detected, the system is assumedto be functioning properly. Otherwise, the system permits the tracing ofduplicates back to their point of origin for investigation andcorrective action. It is desirable, however, to have an electronic cointransfer protocol that precludes the possibility of a duplication ofvalue. An embodiment of such a transfer protocol is presented herein.

Duplicate electronic coins can be the result of deliberate attempts tocreate unauthorized value ("counterfeiting"), or could be the result ofsimple transaction failures. For example, consider the case where anelectronic coin is to be transferred from a payment card to a POS usinga simple transfer protocol, as illustrated in FIGS. 27A-27D and FIG. 28.A payment card 500 contains an electronic coin 500-1 that is to betransferred to a POS 502 (FIG. 27A). The transfer consists of making acopy electronic coin 502-1 of original electronic coin 500-1 within POS502 in a copy operation 504 (FIG. 27B), and then deleting originalelectronic coin 500-1 in payment card 500 with a deletion operation 506(FIG. 27C). Both copy operation 504 and deletion operation 506 aresupervised by a transaction manager 501. After completion of thisprotocol, original electronic coin 500-1 in payment card 500 has beentransformed into copy electronic coin 502-1 in POS 502 (FIG. 27D).Because copies of electronic coins are indistinguishable from originalelectronic coins in this system, this procedure has the net effect oftransferring an electronic coin from the payment card to the POS. Thesteps of this simple protocol are shown in FIG. 28 and consist of a copyoperation 504 followed by a deletion operation 506, as also illustratedin FIG. 27B and FIG. 27C, respectively. Unfortunately, this simpleprotocol suffers from a weakness in that if anything interrupts thecompletion of the protocol, there is the possibility that multiplecopies of a single electronic coin will exist. For example, supposepayment card 500 is disconnected from transaction manager 501 after copyoperation 504 has taken place, but before deletion operation 506 hastaken place. This could happen through a number of natural and possibleevents. In addition to a genuine power failure which disablestransaction manager 501, a consumer might suddenly withdraw his paymentcard from the POS prior to the execution of the deletion operation,either innocently without realizing the effect, or deliberately with theintent to induce such a failure. In any case, the result should be thatthe POS has received an electronic coin credit, but the payment cardstill has the electronic coin available to be spent again (FIG. 29). Incertain prior art implementations of this simple protocol, theelectronic coin is "flagged" by the payment card prior to transfer andretains the internal flag in the event of such a failure. This couldconceivably prevent the electronic coin from being erroneouslyconsidered as a spendable coin, but the information contained in theflag is insufficient to enable an interrupted transfer to be completed.

To eliminate such problems, a transfer protocol can be employed which isfundamentally resistant to electronic coin duplication. One suchprotocol is illustrated in FIGS. 30A-30I and FIG. 31, also in terms of atransfer from a payment card to a POS, although the protocol is generaland would apply equally well in the reverse direction. As with thesimple transfer protocol illustrated above, there is a transactionmanager, but for clarity in the drawings the transaction manager is notshown in FIGS. 30A-30I or FIG. 31. It should first be noted that amonetary transfer is generally defined as a "transaction" in which oneaccount is credited with a certain amount and another account is debitedwith the exact same amount. Transactions are "atomic" or "indivisible"in that (ideally) either the entire transaction is executed or no partof the transaction is executed. In on-line systems, for example, aprovision is made either to "commit" the transaction (to transform bothaccounts to the state of the executed transaction) or to "roll back" thetransaction (to return both accounts to the states they were in prior tothe initiation of the transaction). Traditionally, in the event of aninterruption of the transaction (such as by a power failure), the "rollback" option is taken, in which case the transfer was unsuccessful. Thetransfer could be attempted again, or it could be left unperformed withboth accounts as they originally were. The "commit" option is taken onlyupon the successful completion of the transaction. In either event, theintegrity of the system and the accounts involved is protected. In thepresent case of payment cards and electronic coins, provision for"commit" and "roll back" options would serve to guarantee that thetransfer of an electronic coin would be performed completely or notperformed at all, and would therefore insure that electronic coins areneither created nor destroyed in the course of transfers or attemptedtransfers. Unfortunately, current embodiments of the "commit" and"rollback" features require a central administrator (such as a centralon-line computer) to oversee the transaction, and this is difficult orimpossible to provide in the fluid environment of transfers betweenpayment cards and points-of-sale. Accordingly, in an embodiment of thepresent invention, cryptographic techniques are employed in the transferprotocol to approximate, as closely as possible within the system of thepresent invention, a "commit" and a "roll back" option.

In this protocol, payment card 500 has a public-private keypairconsisting of a public key 500-3 and a private key 500-5 (FIG. 30A).Likewise, POS 502 has a public-private keypair consisting of a publickey 502-3 and a private key 502-5. This protocol can utilize any of thesuitable public key encryption methods well known in the art. Forpurposes of this protocol, public keys need not be certified orauthenticated, and so either party involved in a transfer may obtain thepublic key of the other party to the transfer by a simple request tothat party. In this protocol, public key encryption serves as a one-wayfunction from the perspective of the sender of an electronic coin, toprevent that electronic coin from inadvertently becoming available forspending a second time by the sender. The coin, however, is notimmediately destroyed, but remains for a time with the sender inencrypted form for controlled recovery, in the event that a "roll back"is needed.

In this particular embodiment of the protocol, public key 500-3 andprivate key 500-5 are not utilized in the transfer of electronic coin500-1 from payment card 500 to POS 502, but they are shown here becausethey would be needed for transfer of an electronic coin from POS 502 topayment card 500.

In the first step of the transfer protocol, payment card 500 obtainspublic key 502-3 from POS 502 in a key-exchange operation 510 (FIG.30B). In the second step, payment card 500 encrypts electronic coin500-1 with public key 502-3 to obtain an encrypted electronic coin 500-2in an encryption operation 512 (FIG. 30C). In a preferred embodiment,this encryption is done "in place" so that electronic coin 500-1 isreplaced by encrypted electronic coin 500-2. Thereafter, as far aspayment card 500 is concerned electronic coin 500-1 has been effectively"destroyed" so that no copy of it exists which can be used by paymentcard 500 for any purpose other than the intended transfer to POS 502.Electronic coin 500-1, however, still exists and can be recovered in theevent of failure even though it is unavailable for use by payment card500. In the third step, payment card 500 deletes the local copy ofpublic key 502-3 in a deletion operation 514 (FIG. 30D). In the fourthstep, payment card 500 sends a copy 502-2 of encrypted electronic coin500-2 to POS 502 in a copy operation 516 (FIG. 30E). At this point, twocopies of the original electronic coin exist, but neither is immediatelyusable, since both are encrypted with public key 502-3. In the fifthstep, POS 502 decrypts encrypted electronic coin 502-2 with private key502-5 in a decryption operation 518 to obtain a valid electronic coin502-4, which is the same as original electronic coin 500-1 (FIG. 30F).In the sixth step of the protocol, POS 502 notifies payment card 500that it has electronic coin 502-4. in a notification operation 520 (FIG.30G). In the seventh and final step of the protocol, payment card 500deletes encrypted electronic coin 500-2 in a deletion operation 522,thereby completing the transfer (FIG. 30H). After completion of theprotocol, payment card 500 no longer has electronic coin 500-1, and POS502 has electronic coin 502-4 (FIG. 30I).

An important property of this duplication-resistant protocol is that atno time does the transferred electronic coin exist in unencrypted formin both the payment card and the POS. This means that inadvertent ordeliberate replication of the electronic coin cannot occur. Furthermore,although multiple copies of the encrypted electronic coin may existsimultaneously for a brief period, these are usable only to the intendedrecipient and cannot create a liability to the system if then happen topersist after the transaction is completed. These encrypted electroniccoins could be sent multiple times only to the original intendedrecipient, and the serial number of the electronic coin can, inprinciple, can identify multiple transfers of the same coin to therecipient, should this occur, in which case the recipient would ignorethe extraneous transfers.

It should be noted that this duplication-resistant transfer protocolassumes that both the sender and the recipient (the payment card and thePOS) are trusted, secure devices. This duplication-resistant transferprotocol by itself does not provide protection against duplication ofelectronic coins by an attack in which an attacker impersonates anauthorized sender, such as by presenting a counterfeit or compromisedpayment card. In such a case, the attacker is clearly not bound by therequirement of the protocol, for example, that the electronic coin beencrypted "in place", and can therefore maintain multiple copies of thesame electronic coin in unencrypted form, or may otherwise makeunlimited copies of electronic coins. Additional security measures areneeded to protect against such attacks, and this transfer protocolshould be conducted within a suitably secure environment. For example,the entire session between the payment card and the POS can (and should)be encrypted according to methods well known in the art. The purpose ofthe transfer protocol illustrated herein is to provide a basis fortreating an electronic coin transfer as a transaction in the context ofsecure devices whose interconnectivity and/or power-dependentoperability cannot he guaranteed.

Once the electronic coin that is to be transferred has been encryptedwith the public key of the intended recipient, it becomes permanentlyunavailable for any purpose other than sending to the intendedrecipient. For this reason, although this duplication-resistant transferprotocol provides better recovery from error conditions than the simpletransfer protocol illustrated above (FIG. 27 and FIG. 28), true "commit"and "roll back" operations are not directly provided. Rather, theduplication-resistant transfer protocol retains an interrupted transferin a state that is resumable, and which may be completed at some futuretime, subsequent procedures can effectively implement the "commit" and"roll back" operations. FIG. 31 illustrates the flow of theduplication-resistant transfer protocol as shown in FIG. 30, with someadded features pertaining to maintaining the integrity of thetransaction in the event of interruption. For example, after copyoperation 516, a decision point 517 checks to determine if the copy hasbeen successful. If not, copy operation 516 is retried. It is importantto note that the retry need not be attempted immediately, hut that anarbitrary time can elapse before the retry is made. For example, supposea customer puts a payment card into a POS (such as a vending machine),but the transfer of the electronic coin from payment card to POS issomehow interrupted, such that the payment card encrypts the electroniccoin but the electronic coin is not copied to the POS and thereforeremains with the payment card. At a future time, the customer can returnto the same POS and complete the transaction or obtain a refund.Suppose, however, that the encrypted electronic coin is successfullycopied to the POS but that the transfer protocol is interrupted beforethe encrypted coin can be deleted from the payment card. In that case,if the customer returns to the same POS to resume the transaction,decision point 519 (FIG. 31) checks to determine if the electronic coinhas been previously transferred. If so, the POS deletes the decryptedelectronic coin (this electronic coin is a duplicate) and signals thepayment card to do likewise. If the electronic coin has not beenpreviously transferred, the transaction resumes and completes normally.

It should also be noted that, although it is unsatisfactory forduplicate electronic coins to be created within the system of thepresent invention, the occasional loss of an electronic coin isconsidered to be a tolerable condition. If, for some reason, a transferis interrupted as described above, but the POS becomes permanentlyinaccessible to the payment card, there will generally be no way torecover or use the encrypted electronic coin, and thus the electroniccoin could be effectively lost. It is possible, however, for the issuerof the POS to maintain a copy of the private key of the POS and therebymake it possible to recover the lost electronic coin from the paymentcard to take account of such possibilities.

5. Semi-Countable Electronic Monetary System (FIG. 22-24)

As described hereinabove with reference to statistical analysis of §2.8and FIG. 21, it has been shown that lower-denomination electronic coins(i.e. electronic coins of denomination which is not allowed for manualpurse loading) revolve between cards and POS and between POS andfinancial institutions with no net long-term effect on the system-levelmoney flow. The money flow has been shown there to take place throughtransfers of electronic bills (i.e., electronic coins of higherdenomination allowed for manual reload) and of charge orders. Thisbehavior allows further simplification of the system of the presentinvention, by defining the "semi-countable" concept.

"Electronic penny" will be defined as an electronic monetary instrumenthaving the value of one EMU (elementary monetary unit). The electronicpenny (herein denoted in the drawings as an "E-Penny" for convenience)is similar to an elementary electronic coin in its payment capability;however, an electronic penny has no serial number, and therefore cannothe traced individually. Its storage is essentially in counter devices,which count the number of electronic pennies stored therein. Transfer ofan electronic penny from a source counter device to a target counterdevice involves incrementing the count in the target counter device,while decrementing the count in the source counter device.

FIG. 22, to which reference is now made illustrates schematically asemi-countable embodiment of the present invention. A financialinstitution 220 includes charge accounts 220-A, and an electronic billpool 220-B storing electronic coins of, say $25 each, which are allowedfor manual load into electronic bill purses of payment cards. Anelectronic penny pool 220-P is a counter device, for having therein thenumber of pennies (e.g. of 1¢ value) currently stored at financialinstitution 220. A POS 221 includes a charge drawer 221-A for storingtherein charge orders received from payment cards. POS 221 has anelectronic cash purse 221-C which includes an electronic bill drawer221-B to store therein $25 electronic coins received from payment cards,and an electronic penny drawer 221-P which is a counter device havingthe number of 1¢ pennies currently stored therein.

Payment cards 222, 223 and 224 represent three types which may co-existin the system. Payment card 222 includes a charge card 222-A, having aminimum charge limit of $25 (the charge limit and the electronic billvalue are preferably equal, to simplify the operation of the procedureof FIG. 23 below;). Thus, payment cards 222, 223, and 224 can be used topay amounts of $25 or more; these payment cards also include anelectronic penny purse 222-P, which is a counter device having thenumber of 1¢ pennies currently stored therein. Payment card 223 includesan electronic bill purse 223-B for manually loading thereto and payingtherefrom $25 electronic coins; payment card 223 also includes anelectronic penny purse 223-P. Payment card 224 includes charge card224-A, and also has an electronic cash purse 224-C that includes anelectronic bill purse 224-B and an electronic penny purse 224-P.

FIG. 23 describes the operation of the embodiment of FIG. 22, for payingan amount $SUM with a payment card having $BALANCE in its purse (step231), wherein $BALANCE is the sum of the contents of both the electronicbill purse and the electronic penny purse included in the payment card.At a decision point 232, the feasibility of electronic cash payment ischecked. If an affirmative decision is found, then in a step 233 $SUM ispaid by electronic cash, by any or both electronic bills and electronicpennies with the possibility of payment with electronic bills andreceiving change by electronic pennies (see FIG. 13). At decision point234, payment has been found unfeasible for the current electronic cashin the purse, and therefore payment by charge is checked, i.e. to verifythat the payment card is of type 222 or 224, but not of type 223. Ifcharge in not available, then in step 235 the user is instructed toreload his card manually with a number of electronic bills, or else thepayment is rejected. At decision point 236, a decision is made to pay$SUM through the charge card, or receive $25 via the charge card andreturn $25-$SUM in electronic pennies to the electronic penny purse.

Analysis of this procedure, according to the statistical considerationof described hereinabove, yields the following results:

(a) the amount of electronic pennies stored in electronic penny purse222-P, 223-P or 224-P will be a random number, evenly distributed in therange zero (inclusive) and $25 (exclusive);

(b) the average electronic penny flow into POS 221 equals the averageelectronic penny flow out of POS 221 so there is no net effect on themoney flow.

Consumers are allowed to select three payment cards: 222 for ultimateconvenience (no reload option), 223 for unbanked consumers, and 224 forconsumers who wish to have both ultimate convenience throughincorporating charge card 224-A, but will manually load their electronicbill purse 224-B with sufficient amount of electronic cash, prior tomaking a purchase where privacy is desired (electronic bill payment isnot traceable, while charge payment is traceable).

Bankers may like the present embodiment because of minimal storage anddata transfer requirements for both cards and POS. Because memory isallocated only for electronic coin storage of electronic bills (anelectronic penny purse counting 2500¢ makes do with a two-byte counter),and assuming the storage of 40 or 80 $25 electronic bills, foraccommodating up to $1,000 or $2,000 in each card or POS respectively.FIG. 24 shows that 180 bytes on the card (241-8) and 360 bytes in eachPOS (241-11) are sufficient. If, however, instead of 40 $25 electronicbills the card will accommodate 1 electronic bill of each $25, $50, $10and $200 denomination and two $400 electronic bills, the requiredstorage on the card, for an equivalent performance, becomes 24 bytesonly.

The security behind the semi-countable concept is based on countingelectronic bills as before, while monitoring the electronic pennytransaction statistics between each POS and financial institutions,expecting zero average over a long period. Any POS substantiallydeviating from zero average will indicate a possible flaw in thesystem's security.

6. Multi-Issuer Environment

More than one financial institution may be involved in issuingelectronic cash. In such a situation, a plurality of electronic coinpools shall be maintained in the same system of the present invention.In such situations, a range of separate serial numbers will be allocatedto each financial institution. When electronic coins are to be movedfrom POS to financial institutions (transactions 217 and 218 of FIG.21), they sill be routed to the respective financial institutionaccording to their serial number. This sorting and routing will takeplace either at the POS level, or at the level of intermediateprocessing centers (not shown in FIG. 21), similarly to the techniquesused commonly to route charge transactions to the respective financialinstitutions (219 in FIG. 21).

7. Card-To-Card Transfer

Card-to-card transfer is a desirable feature in any electronic cashsystem, for enabling person-to-person (e.g. parent to child)transactions. Such transactions were in conflict with "accountable"systems of the prior art, but are supported effectively under thepresent invention. When two cards interface through a transaction device(essentially similar to purse-to-drawer interface), transfer ofelectronic coins (each with its serial number) will maintain theintegrity of the system under the present invention.

It should be noted, however, that, unlike in the case of card-to-POStransaction where the POS is primed with a sufficient amount ofelectronic coins of each denomination to enable flawless payment of anyamount, card-to-card transactions are limited according to theelectronic coins actually stored in both cards, thus a parent having acard of FIG. 17 currently having only two $5 electronic coins, will beable to transfer to his child's card currently storing a single $1electronic coin, only an amount of $4, $5, $9 or $10.

8. Anonymity and Privacy

It would be appreciated that while there is a tight monitoring on eachindividual electronic coin in the system, this monitoring does notinvolve tracking of individual cards or card bearers, thus preservingcustomer anonymity and privacy, which is an important object of thepresent invention.

9. Recovering the Value Stored in Lost or Damaged Cards (FIGS. 25-26)

Referring to FIG. 16, card types 165 and 166 allow manual reload ofelectronic bills. Practically, such manual reloads may reach substantialvalues, e.g., $500 to $1,000. If a card is lost, stolen or broken,substantial damage may occur to the card owner. According to an aspectof the present invention, such damage may be minimized by recording theserial numbers of electronic bills loaded onto a payment card, andrecovering the value of unused electronic bills when these electronicbills expire. Thus, when approaching a loading terminal, e.g. a specialATM, for a manual reload, paving for the loaded electronic bills withany monetary instrument acceptable at this terminal (cash, any chargecard, etc.), the serial numbers of the loaded electronic bills arerecorded for further possible claims.

FIG. 25 (see also FIG. 20 and the related text) describes a preferredembodiment, where the user identifies himself at the loading terminal,e.g. by his credit card. The user identification data is transferred tothe appropriate electronic bill pool related to each loaded electronicbill, where a user ID 257-i is recorded in respect to serial number i,while a status bit 256-i is turned to 0, signaling that thecorresponding electronic bill has been moved from the electronic billpool to an electronic bill purse.

FIG. 26 describes another preferred embodiment, where the serial numbersof the loaded electronic bills 262 are recorded on paper slip 260 by theloading terminal along with a loading date 261; a confirmation code 263is supplied by the terminal or the electronic cash pool, to authenticatethe entire slip's information.

Upon the expiration date, unused electronic bills (i.e. electronic billsthat have not been returned to the respective electronic bill pool), canbe identified automatically by an embodiment of the present invention.In the embodiment of FIG. 25, the original latest ownership of eachunused electronic bill with serial number i can be identified from therespective register 257-i; in the embodiment of FIG. 26, such originallatest ownership can be determined by the user who presents a slip 260having the latest loading date 261. Upon receiving, a claim for thevalue of a lost or damaged card, the financial institution may pay theuser the value of the unused electronic bills.

To enhance security in the situation under consideration, a PIN may berequired for any transaction that involves spending electronic bills. Inthis way, the electronic bills in a lost or stolen card will remainunusable, and therefore recoverable on the expiration date.

10. General Comments

It will be appreciated that, for both payment cards and POS units,whenever a plurality of storage devices is mentioned, the presentinvention relates to logical memory management, and not necessarily toseparate chips. For instance, a single hardware chip on a payment cardcan accommodate a charge card and a number of electronic coin purses.

It would be also be appreciated that whenever an apparatus (paymentcard, POS or financial institution computer) is described to includeseparate units to perform separate functions, such separation isbasically logic, and several or all functions can be actually executedby a single microprocessor; also, in some cases when two apparatuses aredescribed to interact to execute a mutual function such as transfer ofmoney from one apparatus to another, some of the units described to beincluded in one apparatus can actually be moved to the other apparatusto perform their function from there.

The parity bits added to each electronic coin's serial number can takeinto account also the electronic coin's edition and denomination, thusenhancing the system's security and reliability.

The term "serial number" should be interpreted broadly, as anyrecordable data included in an electronic coin, identifying it andmoving with it. It may contain electronic representation of any relevantidentification data, such as issuer identification, issue date,expiration date, etc.

11. Extended Security Monitor

The present invention can he expanded and extended to offer acomprehensive electronic cash security scheme as follows (reference ismade to FIG. 21):

a. Each electronic bill 210 flowing from bank to card, each electronicbill 212 flowing from card to POS, and each electronic bill 212 flowingfrom POS to financial institution, including the transaction path viaall stored-value devices involved, is reported to the electronic billpool at the financial institution. Any mismatch is easily interrogatedby the data available in the electronic pool. The term "transactionpath" denotes the sequence of devices that have engaged in successivetransactions with a specific instance of electronic cash, wherein thesequence of devices terminates at a financial institution. The term"intersection", when used with reference to a transaction path, denotesany device which is in common with two or more transaction paths.

b. Card-to-card transfer of electronic bills is allowed for one transfer(or a small number of transfers) only. In this case, the identity of thefirst card will be concatenated to the serial number, and flow with theserial number up to the electronic bill pool, thus maintaining acomplete transaction path tracking.

c. Each POS and each intermediate computer in the settlement chain(normally, transaction information flows from a POS to central banks viaseveral intermediate computers, e.g. local, regional, etc., not shown inFIG. 21), records each received electronic coin alone with the identityof the source device which has supplied this electronic coin. This datais kept, normally passively, for about one month, and then its memoryspace is freed for further data recording. The embodiments according tothe present invention which utilize this data arc discussed in detailbelow.

d. Each link in the settlement chain maintains a "statistical trap", tomeasure statistical moments of electronic coins flowing therethrough.Since electronic coin flow statistics are predictable, abnormalities(i.e. exceeding predefined statistical thresholds) will trigger anaccelerated refreshing rate at all intermediate computers and POS belowthe device operating the respective alerting, statistical trap.

e. Any electronic coins having an out-of-range or duplicate serialnumber that are found in the electronic coin pool, will triggerautomatically a systematic query, wherein each device identified assupplying the electronic coin will be queried to provide information onthe previous supplier of the electronic coin, down to the respective POSidentifying the payment card. The reconstructed path will be used forhuman interrogation and intervention. The term "invalid electronic coin"herein denotes any electronic coin having an out-of-range serial numberor a serial number which is identical to another electronic coincurrently in circulation.

11.1. A Continuous Electronic Coin Sampling Watchdog

It will be appreciated that the security scheme described aboveincorporates complete electronic bill accountability and, at theelectronic coin level, a combination of distributed, localized, passivedata collection which is normally dormant, with very alert watchdogs(continuous electronic coin sampling; statistical traps). When thewatchdog barks, a highly efficient, systematic query identifies theexact transaction path of invalid electronic coins for humanintervention. An embodiment of a method according to the presentinvention for auditing the system to discover the presence and source ofinvalid electronic coins is described below. The auditing aspects of themethod can also be applied to tracing the origin of an electronic cash,including electronic bills, but are illustrated for electronic coinsonly.

During a certain period of time, a number of transactions involving thespending of electronic coins takes place. It is desired to detect if,during this time period, any of the electronic coins in circulation areduplicates or are out-of range, and, if so, what is the source of theseinvalid electronic coins. While duplicate or out-of-range electroniccoins, representing unauthorized creation of value, are not permittedunder the system of the present invention, an occasional invalidelectronic coin is not a cause for alarm, as the values of electroniccoins are low enough to limit the risk exposure which such electroniccoins pose. Furthermore, because electronic coin editions according tothe present invention have a limited lifetime, invalid electronic coinsare automatically removed from circulation at regular intervals.Moreover, it is anticipated that the normal attrition of electroniccoins due to losses (such as in lost or damaged payment cards) willalways exceed the number of invalid electronic coins that may come intoexistence through natural stochastic processes (such as normal dataerrors). Counterfeit electronic coins, however, are invalid electroniccoins that are intentionally created by attackers in an effort to cheatthe system, and thereby pose a threat to the system's integrity. Ifcounterfeit electronic coins occur at all, the occurrences would be morethan just occasional, so it is important to be able to trace counterfeitelectronic coins to their source. The term "bogus electronic coin"herein denotes an invalid electronic coin which appears to be acounterfeit electronic coin, but has not yet been confirmed byinvestigation to be a counterfeit electronic coin. The purposes of thecontinuous electronic coin sampling watchdog according to the presentinvention are therefore:

1. to determine if bogus electronic coins are in circulation;

2. if bonus electronic coins are not in circulation, to confirm this andthereby to establish a degree of confidence in the integrity of thesystem;

3. if bogus electronic coins are in circulation, to determine if theoccurrences are serious enough to warrant further investigation; and

4. if the occurrences of bogus electronic coins warrant furtherinvestigation, to provide information leading directly to the source ofthe bogus electronic coins.

The continuous electronic coin sampling watchdog must work efficientlyand be enabled at all times, yet not impose an undue burden of dataprocessing on the system. That is, the continuous electronic coinsampling watchdog should operate invisibly in the background. This goalis attained by the present invention, as illustrated below, for a caseinvolving a bogus electronic coin in the form of an invalid electroniccoin that has been put into circulation twice by the same payment card.

It should first be noted that there is nothing inherently wrong inhaving a payment card spend the same electronic coin more than once.Because electronic coins according to the present invention circulate,it is to be expected that a payment card will occasionally receivechange that includes an electronic coin which was previously spent bythat same payment card. A problem arises, however, when a payment card(or other device) spends an electronic coin that is presently incirculation elsewhere in the system, for this represents a duplicationof value. The method according to the present invention of detectingsuch an invalid electronic coin at the electronic coin pool is bothefficient and economical, and furthermore is able to identify thesources or sources of the duplicate electronic coins. The method canalso be applied to detecting the sources of out-of-range electroniccoins.

A preferred embodiment of the present invention for detecting duplicateelectronic coins is illustrated in FIG. 32, to which reference is nowmade. Payment cards 600, 610, 620, 630, and 640 spend electronic coins680, 682, 684, 686, and 688, respectively. Payment card 600, however,spends electronic coin 680 more than once, and thus electronic coin 680appears as a duplicate electronic coin. For example, payment card 600might be defective, or might have been compromised by an attacker inorder to produce and spend counterfeit electronic coins. In any case,electronic coin 680 is spent at a POS 650 and also, during the same(general time period, at a POS 660. (Payment card 600 and electroniccoin 680 are emphasized in FIG. 32 to more readily distinguish them.)For the purpose of this example, it is assumed that electronic coin 680is a counterfeit electronic coin, rather than merely an invalidelectronic coin that has arisen incidentally from natural stochasticprocesses, such as data errors. However, the fact that electronic coin680 is an intentional counterfeit cannot be absolutely determinedwithout a thorough investigation, and therefore electronic coin 680 isreferred to as a bogus electronic coin for this example.

POS 650 maintains a received electronic cash file 655 and POS 660maintains a received electronic cash file 665. As illustrated in FIG.33, and as detailed below, a received electronic cash file containsrecords of each item of electronic cash received by a device during thecourse of a particular time period. In particular, the transactionrecords of received electronic cash file 665 and received electroniccash file 665 contain the serial number of each electronic coin whichthe POS has received during the time period along with the identity ofthe transferring, device that supplied the electronic coin, which, inthis case, will be a payment card. As noted previously, this data iskept passively by the POS for a limited time. A certain amount of memoryis allocated for these transaction records, and once the memory is full,new transaction records systematically replace the transaction recordscorresponding to the transactions having the earliest transaction date.The amount of time a specific received electronic cash file is retainedcan be increased by increasing the memory allocated in the POS for thereceived electronic cash file, and should be sufficient to retain aspecific transaction record long enough that the electronic coin of thetransaction will circulate back to the financial institution forstatistical verification, as described below. In general, a receivedelectronic cash file contains transaction records with an electroniccash identification field corresponding to arbitrary forms of receivedelectronic cash, such as electronic bills as well as electronic coins.In general, also, a received electronic cash file contains transactionrecords with a transferring device identification field which containsthe identifier for the device that transferred the electronic cash.Transferring devices include, but are not limited to, payment cards,points of sale, and intermediate stored-value devices as noted below.

Returning to FIG. 32, subsequent to the initial transactions at POS 650and POS 660, the process of normal circulation augmented by the mixingand refreshing processes according to the present invention, causeselectronic coins 680, 682, 684, 686, and 688 from POS 650 and POS 660 toreach a financial institution 670 via optional one or more intermediatestored-value devices between financial institution 670 and the level ofPOS 650 and POS 660. Intermediate stored-value devices includecomputers, servers, and special-purpose devices used to collect ortransfer electronic cash from one device to another. Some genericintermediate stored-value devices (hereinafter referred to simply as"intermediate devices") are illustrated in FIG. 32 as an intermediatedevice 652 and an intermediate device 662, with ellipsis (. . . )indicating the option of additional intermediate devices in the chain.Intermediate device 652 maintains a received electronic cash file 657and intermediate device 662 maintains a received electronic cash file667. Because electronic coin 680 has been spent twice during thespecified time interval (even at different POS terminals), there is ahigh probability that the two copies of electronic coin 680 willsubsequently be found at financial institution 670 at overlapping times.The presence of the duplicate will he detected immediately by financialinstitution 670 when the electronic coin pool is updated, since thepresence of a coin in the electronic coin pool is indicated by thesetting of a bit corresponding to the serial number of electronic coin680. Financial institution 670 maintains a received electronic cash file675 which lists each electronic coin and the identity of thetransferring device (such as a point of sale or intermediate device)which supplied the electronic coin to financial institution 670. Ingeneral, the transferring device can be any device which is appropriateto transfer electronic cash to the receiving device, including paymentcards as well as points of sale and intermediate devices.

FIG. 33 shows the details of received electronic cash file 675, receivedelectronic cash file 665, and received electronic cash file 655. Forsimplicity, FIG. 33 shows the chain of electronic coin transfers to befrom POS 650 and POS 660 directly to financial institution 670 (FIG.32), without intervening devices, such as device 652 and device 662(FIG. 32). Therefore, received electronic cash file 675 shows POS 650and POS 660 as the devices from which financial institution 670 receivedthe electronic coins in question. The method presented herein isgeneral, however, and operates effectively regardless of what devices,if any, are in the chain between the POS and the financial institution.The method is illustrated for the general case in the flowchart of FIG.35, which is described in detail below. Returning to FIG. 33, atransaction record 675-1 has fields specifying the date of thetransaction, the electronic coin serial number and value, and the devicefrom which the electronic coin was obtained. When financial institution670 (FIG. 32) detects a duplicate of electronic coin 680 in theelectronic coin pool, received electronic cash file 675 is consulted todetermine the immediate sources of electronic coin 680 (FIG. 33). It isseen that transaction record 675-1 and another transaction record 675-2both show the arrival of electronic coin 680. Transaction record 675-1shows that the first duplicate of electronic coin 680 came from POS 650,and transaction record 675-2 shows that the second duplicate ofelectronic coin 680 came from POS 660. At this point, POS 650 is queriedto obtain selected data from received electronic cash file 655, and POS660 is queried to obtain selected data from received electronic cashfile 665. In both cases, the selected data consists of relevant recordsfrom the respective received electronic cash files, as illustrated bythe example of FIG. 33. It is next seen that received electronic cashfile 655 contains a transaction record 655-1 which shows that the firstduplicate of electronic coin 680 originally came from payment card 600,and that received electronic cash file 665 contains a transaction record665-1 which shows that the second duplicate of electronic coin 680 alsooriginally came from payment card 600. At this point, the source of theduplicate electronic coins has been pinpointed and the relevantinformation can be reported and used for farther investigation, ifwarranted.

In the manner shown above, the original source of a bogus electroniccoin can be quickly and economically determined. Note that this methoddoes not require the storage and preservation of a vast quantity ofarchival data concerning transactions, but only a modest amount of dataconcerning relatively recent transactions. Moreover, this data isdistributed throughout the system, does not need to be centralized, andcan be acquired and maintained by devices already present in the systemat negligible cost. Furthermore, unless there is a need to do so, noanalysis is performed on the transaction data, and even when there is aneed, the analysis is relatively simple. Thus, according to the presentinvention, the keeping of transaction data and the analysis as neededdoes not place any undue burden on the system, but is immediatelyresponsive to any conditions that warrant attention.

The general procedures for obtaining information about the source of abogus electronic coin that arrives at the electronic coin pool of afinancial institution are illustrated in FIG. 34 and FIG. 35. Thesemethods are illustrated for locating the source of a bogus electroniccoin but also apply to locating the source of a genuine electronic coin.In FIG. 34, the financial institution merely maintains an alert forincoming bogus electronic coins. As noted previously, an electronic coinin the electronic coin pool is represented as a set bit in a serialnumber vector, so if a duplicate electronic coin or out-of-rangeelectronic coin arrives at the electronic coin pool, it will beimmediately detected using negligible effort, without the need for anydata searching or comparisons. This alert for incoming bogus electroniccoins is represented in FIG. 34 by a decision point 700, which loopsback upon itself if no bogus electronic coin is detected. If a boguselectronic coin is detected, then in a step 710, the transaction recordsfor that electronic coin are retrieved from the received electronic coinreceived electronic cash file of the electronic coin pool. Followingthis is a loop starting at a loop start 720 and ending at a loop end740, containing a step 730 in which the transaction path correspondingto each of the retrieved records is added to a list of transactionpaths. When loop end 740 reaches the final record of the recordsretrieved in step 710, the loop exists, and the list of transactionpaths is processed in a step 750 to find intersections in thetransaction paths. Finally, a report output procedure 760 issues areport for human use by investigators, who can pursue the matter asnecessary.

A recursive method of deriving a transaction path for an electronic coinin the electronic coin pool is illustrated in the flowchart of FIG. 35.The method starts by setting the current device to the financialinstitution's electronic coin pool in a step 800. Next in a step 810,the received electronic coin received electronic cash file of thecurrent device is obtained. At the beginning of this recursive method,this means the received electronic coin received electronic cash file ofthe electronic coin pool will be obtained. As the recursion proceeds,however, the current device will change. Next, the serial number of thesubject electronic coin (the electronic coin whose transaction path isdesired) is input as data 820, and in a step 830 the device thatpreviously handled the subject electronic coin is obtained, and in astep 840 the previous device is added to the transaction path. At adecision point 860, it is determined whether the previous device has areceived electronic coin received electronic cash file. If the previousdevice does not have a received electronic coin received electronic cashfile (for example, a payment card does not maintain a receivedelectronic coin received electronic cash file), the method is completeand a transaction path 870 is output. If, however, the previous devicedoes have a received electronic coin received electronic cash file, astep 850 sets the current device to the previous device and loops backto step 810.

In general, the method of locating the source of bogus electronic coinsaccording to the present invention is therefore to compile thetransaction paths for a number of bogus electronic coins and examine thetransaction paths for intersections with the same device or devices.Devices which appear at or near such intersections are likely sourcesfor the bogus electronic coins and should he investigated further.

It is noted that human investigation is ultimately needed because thereare several different electronic coin tracing scenarios possible whendealing with bogus electronic coins, and the automated informationobtained as described above may not in itself be conclusive, but mayonly provide indicia of a source of bogus electronic coins. For example,it is conceivable that POS 650 (FIG. 32) might have dispensed electroniccoin 680 to another payment card 605 (not shown) as change rather thansent electronic coin 680 on to financial institution 670, and thatpayment card 605 would have subsequently spent electronic coin 680 at aPOS 652 (not shown), which later sent electronic coin 680 to financialinstitution 670. In this case, there will be no record at financialinstitution 670 that POS 650 was ever involved with the transaction pathof electronic coin 680. When financial institution 670 traces the pathof electronic coin 680 back to original sources, the result will onlyshow that payment card 600 spent one of the duplicates at POS 660, andthat payment card 605 spent another of the duplicates at POS 652. Thisis not sufficient information to identify payment card 600 as the sourceof both duplicates. However, if a payment card is the source of a largenumber of bogus electronic coins, there is a reasonable probability thatthe payment card will appear in a statistically significant number oftransaction paths involving the bogus electronic coins, and cantherefore be detected.

It is also noted that payment cards are not the only suspects whentracing down the source of bogus electronic coins. A POS, for example,could also be a source of bogus electronic coins if it were somehowcompromised by a dishonest merchant. In such a case, it would beexpected that the POS would issue its bogus electronic coins as change,rather than send them directly up to the financial institution. In thisway, the bogus electronic coins would be spent by unknowing customers ata variety of other (also innocent) POS devices before finding their wayto the financial institution and being detected. The result would bethat the compromised POS generating and distributing the boguselectronic coins would not appear in any transaction path. Instead, itwould be expected that there would be a set of transaction paths for thebogus electronic coins that would be localized in the vicinity of thecompromised POS. To uncover the identity of the compromised POS, itwould be necessary for human investigators to deduce a connectionbetween the various payment cards at the base of the transaction paths.This connection would be the compromised POS, and while automated toolscould assist in this investigation, human intervention would benecessary to guide the investigation.

12. Aggregation of Transactions by Merchant

FIG. 21 describes the relations between a single POS, cards andfinancial institutions, showing how revenues are carried by charges andelectronic bills while electronic coins revolve via payment, change,adjustment and refreshing, with zero average effect. It would beappreciated that a merchant operating a plurality of POS units (e.g. asupermarket,) may actually consolidate the various POS drawers of thesame function (e.g. see 172 in FIG. 17), each into a single,merchant-level drawer, maintaining a similar statistical behavior as ina single POS. Thus, FIG. 21 represents also a case where the "POS" blockis replaced by a "MERCHANT" block actually representing the flow ofelectronic bills, charges and electronic coins through a consolidatedplurality of POS.

13. A Central Electronic Coin Issuer and Multiple Electronic BillIssuers

As has been demonstrated in FIG. 21, revenues are actually carried byelectronic bills and charge orders, while electronic coins revolve, withaverage zero net between cards and POS and between POS and financialinstitutions. The function of electronic coins thus becomes mostlytechnical, to enable small payments by larger-value charges andelectronic bills. It might be preferable, in some systems, to have thesmaller electronic coins issued by a single source, e.g. the systemoperator or coordinator, while electronic bills can be issued by andsettled with a plurality of issuers. Thus, smaller electronic coins willbe originated in and flow through a single electronic coin pool foradjustment and refreshing, while electronic bills will be purchased fromissuers to be loaded into electronic purses, and later directed frompoints of sale to the respective issuers' pools for settlement.

14. Editions of Electronic Pennies

FIGS. 22-24 have introduced electronic pennies, which are actuallycounters of EMU value units. It is noted that if a new edition is issued(§3 above and FIGS. 19-20). new electronic pennies will also be issued.New and old electronic pennies will be stored and moved separately amongseparate partitions in all stored-value devices (similarly to FIGS. 19and 20), with preference of moving, old electronic pennies (via payment,change, adjustment and refreshing) toward the pools and new electronicpennies toward purses, just effectively draining the system from oldelectronic pennies. Old electronic pennies will be accumulated in an"old" partition at the electronic penny pool, and on the expiration datethey will be counted, with a precision of 1 EMU, to effectively confirmthe security and integrity of the payment system. It is noted, however,that this method is less accurate with electronic pennies than withelectronic coins, since unused electronic pennies may unnoticeablycompensate for counterfeit electronic pennies.

It will be further appreciated by persons skilled in the art that thepresent invention is not limited to what has been particularly shown anddescribed hereinabove. Rather the scope of the present invention isdefined only by the claims which follow:

What is claimed is:
 1. A countable electronic monetary system for thetransfer of electronic money in amounts which are an integer multiple ofan elementary monetary unit, the transfer of electronic money madebetween two selected ones from a plurality of payment cards, a pluralityof points of sale and a number of financial institutions, the countableelectronic monetary system comprising:a) at least one electronic cointype, each electronic coin type of said at least one electronic cointype having a denomination of an integer number of said elementarymonetary unit; b) a plurality of electronic coins each belonging to oneof said at least one electronic coin type, each electronic coin of saidplurality of electronic coins having a serial number; c) a plurality ofstored-value devices, each for storing electronic coins from saidplurality of electronic coins, comprising:i. a plurality of electroniccoin purses, each included in a payment card of the plurality of paymentcards; ii. a plurality of electronic coin drawers, each included in apoint of sale of the plurality of points of sale; and iii. a number ofelectronic coin pools, each included in a financial institution of thenumber of financial institutions; and d) transaction means for thetransfer of a selectable number of electronic coins belonging to aselectable electronic coin type, from a source stored-value deviceselected from said plurality of stored-value devices to a another,target stored-value device selected from said plurality of stored-valuedevices, said transaction means being operative to recording the serialnumber of each one of said selectable number of electronic coins in saidtarget stored-value device and to erase said serial number from saidsource stored-value device, said transaction means being furtheroperative, when transferring electronic coins from a stored-valuedevice, to pick the transferred electronic coins according topreselected picking criteria.
 2. The system of claim 1, wherein one ofsaid at least one electronic coin type is an elementary electronic cointype having a denomination of one said elementarw monetary unit.
 3. Thesystem of claim 1 wherein said transaction means comprise:a. paymenttransaction means in which said source stored-value device is anelectronic coin purse and said target stored-value device is anelectronic coin drawer; and b. change transaction means in which saidsource stored-value device is an electronic coin drawer and said targetstored-value device is an electronic coin purse.
 4. The system of claim1, wherein said at least one electronic coin type is a plurality ofelectronic coin types of different denominations.
 5. The system of claim4, wherein said transaction means comprise transaction selection meansoperative, upon receiving an amount to be paid, and upon a selectedpoint of sale interfacing with a selected payment card, and according tothe amount of electronic coins belonging to each of said plurality ofelectronic coin types stored in the electronic coin purse of saidselected payment card, to automatically select, for each electronic cointype of said plurality of electronic coin types:a. a first group of anon-negative number of electronic coins from said electronic coin typeto be transferred from the electronic coin purse of said selectedpayment card to the electronic coin drawer of said selected point ofsale; and b. a second group of a non-negative number of electronic coinsfrom said electronic coin type to be transferred from the electroniccoin drawer of said selected point of sale to the electronic coin purseof said selected payment card.
 6. The system of claim 1, furthercomprising:a. at least one charge card included in one of the pluralityof payment cards; b. at least one charge drafter included in one of theplurality of points of sale; and c. at least one account correspondingto said at least one charge card and included in one of the number offinancial institutions; d. and wherein said transaction meanscomprises:i. payment transaction means operative to transfer electroniccoins from an electronic coin purse to an electronic coin drawer; ii.change transaction means operative to transfer electronic coins from anelectronic coin drawer to an electronic coin purse; iii. chargetransaction means operative to pay from an account via the correspondingcharge card; and iv. transaction selection means operative, uponreceiving an amount to be paid, and upon a selected point of saleinterfacing with a selected payment card including a charge card and anelectronic coin purse, and according to the electronic coins stored insaid electronic coin purse, to automatically select:a) a non-negativeamount to be paid through the charge card; b) a first group of anon-negative number of electronic coins to be transferred from theelectronic coin purse of said selected payment card to the electroniccoin drawer of said selected point of sale; and c) a second group of anon-negative number of electronic coins to be transferred from theelectronic coin drawer of said selected point of sale to the electroniccoin purse of said selected payment card.
 7. The system of claim 1,further having at least two editions, and wherein:each of said pluralityof electronic coins is assigned an edition selected from said at leasttwo editions; each of said plurality of stored-value devices isoperative to separating electronic coins according to their assignededition; and said transaction means is operative to establishing apriority for the transfer of electronic coins of a first selectableedition with respect to the transfer of electronic coins of a secondselectable edition.
 8. The system of claim 1, further having, for eachof said at least one electronic coin type:a. a predefined number ofallowed repetitions for any serial number of electronic coins belongingto said at least one electronic coin type; and b. at least one of saidnumber of electronic coin pools having security means to count thenumber of repetitions of each of said serial number of electronic coinsbelonging to said electronic coin type and stored in said electroniccoin pool, and identify and report serial numbers whose repetitionexceeds said predefined number of allowed repetitions.
 9. The system ofclaim 1, wherein said number of electronic coin pools is at least twoelectronic coin pools, and wherein, for a selected electronic coin typefrom said at least one electronic coin type each of said at least twoelectronic coin pools is assigned a distinctive group of serial numbersof electronic coins belonging to said selected electronic coin type. 10.The system as in claim 1, wherein at least one of the plurality ofpoints of sale comprises:a. means for creating and storing a receivedelectronic cash file, said received electronic cash file containingrecords including an electronic cash identification field for eachinstance of electronic cash received from a payment card and atransferring device identification field for said payment card; and b.means for retrieving and delivering data from said received electroniccash file.
 11. The system as in claim 1, wherein at least one of thenumber of financial institutions comprises:a. means for creating andstoring a received electronic cash file, said received electronic cashfile containing records including an electronic cash identificationfield for each instance of electronic cash received from a transferringdevice, and a transferring device identification field for saidtransferring device; and b. means for retrieving and delivering datafrom said received electronic cash file.
 12. The system as in claim 11,wherein at least one of the number of financial institutions furthercomprises means for requesting, storing, and delivering data from areceived electronic cash file from a transferring device.
 13. The systemas in claim 1, further comprising at least one intermediate device, saidat least one intermediate device operative to receiving, storing, andtransferring electronic cash.
 14. The system as in claim 13, whereinsaid at least one intermediate device comprises:a. means for creatingand storing a received electronic cash file, said received electroniccash file containing records including an electronic cash identificationfield for each instance of electronic cash received from a transferringdevice, and a transferring device identification field for saidtransferring device; and b. means for retrieving and delivering datafrom said received electronic cash file.
 15. The system as in claim 14,wherein said at least one intermediate device further comprises meansfor requesting, storing, and delivering data from a received electroniccash file from a transferring device.
 16. The system of claim 1, furthercomprising electronic pennies having no serial numbers.
 17. A method forthe establishment, storage and transfer of electronic monetary values inamounts which are an integer multiple of an elementary monetary unit,within a monetary system having a plurality of stored-value devices toelectronically store monetary values therein, said plurality ofstored-value devices including a plurality of payment cards withelectronic coin purses, a plurality of points of sale with electroniccoin drawers, and at least one electronic coin pool of a financialinstitution, said method comprising the steps of:determining at leastone electronic coin type, each having a denomination of an integernumber of the elementary monetary unit; generating, for each of said atleast one electronic coin type, a selectable plurality of electroniccoins each having the denomination of said electronic coin type and aserial number; depositing, in each of said plurality of stored-valuedevices, a group of a non-negative number of electronic coins, theserial number of each electronic coin deposited in a storage devicewritten onto this storage device; and performing transactions bytransferring selectable electronic coins of selectable electronic cointypes from a selected source stored-value device to a selected targetstored-value device, both selected from said plurality of stored-valuedevices, by writing the serial number of each of said selectableelectronic coins onto said target stored-value device and erasing saidserial number from said source stored-value device, wherein saidperforming transactions further includes picking the transferredelectronic coins according to preselected picking criteria.
 18. Themethod of claim 17, wherein one of said at least one electronic cointype is an elementary electronic coin type having denomination of oneelementary monetary unit.
 19. The method of claim 17, wherein saidstored-value devices include purses and drawers, and wherein saidperforming transactions comprises:performing a payment transaction,wherein said source stored-value device is a purse and said targetstored-value device is a drawer; and performing a change transaction,wherein said source stored-value device is a drawer and said targetstored-value device is a purse.
 20. The method of claim 17, wherein saidat least one electronic coin type is a plurality of electronic cointypes of different denominations.
 21. The method of claim 20, wherein,upon receiving an amount to be paid, upon a selected drawer interfacingwith a selected purse, and according to the amount of electronic coinsbelonging to each of said plurality of electronic coin types stored insaid purse, said performing transactions further comprises the step ofautomatically calculating and selecting, for each electronic coin typeof said plurality of electronic coin types;a first group of anon-negative number of electronic coins from said electronic coin typeto he transferred from the electronic coin purse of said selectedpayment card to the electronic coin drawer of said selected point ofsale; and a second group of a non-negative number of electronic coinsfrom said electronic coin type to be transferred from the electroniccoin drawer of said selected point of sale to the electronic coin purseof said selected payment card.
 22. The method of claim 17, wherein themonetary system further includes at least one payment card with a chargecard and at least one point of sale with a charge drawer, the methodfurther comprising the steps of:automatically selecting a non-negativeamount to be paid via a payment card charge card, said non-negativeamount selected according to the electronic coins in the payment cardelectronic coin purse; automatically selecting a first group of anon-negative number of electronic coins from said electronic coin typeto be transferred from the payment card electronic coin purse to thepoint of sale electronic coin drawer said first group of a non-negativenumber of electronic coins selected for each electronic coin type andaccording to the electronic coins in the electronic coin purse; andautomatically selecting a second group of a non-negative number ofelectronic coins from said electronic coin type to be transferred fromthe point of sale electronic coin drawer to the payment card electroniccoin purse, said second group of a non-negative number of electroniccoins selected for each electronic coin type and according to theelectronic coins in the electronic coin purse.
 23. The method of claim17, further comprising the steps of:defining at least two editions;assigning an edition selected from said at least two editions to eachelectronic coin; and establishing the priority of the transfer ofelectronic coins of a first selectable edition with respect to thetransfer of electronic coins of a second selectable edition.
 24. Themethod of claim 17, further comprising the steps of:defining, for eachof said at least one electronic coin type, a predefined number ofallotted repetitions for any serial number of electronic coins belongingto this electronic coin type; and counting for each electronic cointype, in a pool of said at least one pool, the number of repetitions ofeach serial number of electronic coins belonging to said electronic cointype and stored in said pool, and identifying and reporting serialnumbers whose repetition exceeds said predefined number of allowedrepetitions.
 25. The method of claim 17, wherein said at least one poolis at least two pools, further comprising, for a selected electroniccoin type from said at least one electronic coin type, the stepsof:assigning to each of said at least two pools a distinctive group ofserial numbers of electronic coins belonging to said selected electroniccoin type; and selecting, when said performing transactions is performedto transfer electronic coins belonging to said selected electronic cointype to a pool, the pool for each of the transferred electronic coins inaccordance to the assignment of said distinctive group to which theserial number of the transferred electronic coin belongs.
 26. The systemof claim 1, wherein said preselected picking criteria are selected fromthe group consisting of random electronic coin picking andfirst-in-first-out electronic coin picking.
 27. The method of claim 17,said preselected picking criteria are selected from the groupconsisiting of random electronic coin picking and first-in first-outelectronic coin picking.
 28. A countable electronic monetary system forthe transfer of electronic money in amounts which are an integermultiple of an elementary monetary unit, the transfer of electronicmoney made between two selected ones from a plurality of payment cards,a plurality of points of sale and a number of financial institutions,the countable electronic monetary system comprising:a) at least oneelectronic coin type, each electronic coin type of said at least oneelectronic coin type having a denomination of an integer number of saidelementary monetary unit; b) a plurality of electronic coins eachbelonging to one of said at least one electronic coin type, eachelectronic coin of said plurality of electronic coins having a serialnumber; c) a plurality of stored-value devices, each for storingelectronic coins from said plurality of electronic coins, comprising:i.a plurality of electronic coin purses, each included in a payment cardof the plurality of payment cards; ii. a plurality of electronic coindrawers, each included in a point of sale of the plurality of points ofsale; and iii. a number of electronic coin pools, each included in afinancial institution of the number of financial institutions; d)electronic pennies having no serial numbers; and e) transaction meansfor the transfer of a selectable number of electronic coins belonging toa selectable electronic coin type, from a source stored-value deviceselected from said plurality of stored-value devices to a another,target stored-value device selected from said plurality of stored-valuedevices, said transaction means being operative to recording the serialnumber of each of one of said selectable number of electronic coins insaid targer stored-value device and to erase said serial number fromsaid source stored-value device.